How to establishing an architecture using Azure services ?

How to establishing an architecture using Azure services ?

This threshold applies to the number of receive operations performed on a Service Bus entity. The number of concurrent receive requests on a queue, topic, or subscription entity Each of our entities can simultaneously handle no more than 5000 receive requests. In the case of topic subscriptions, these receive operations are shared by all topic subscriptions.

The entity will throw an exception to the receiver and reject any subsequent receive requests until the number of requests is lower once it reaches this limit. Once more, the option to use an exponential backoff retry strategy when receiving messages from our Service Bus entity is available to deal with this limitation. Reduce the total number of receivers as an alternative. Retries Retrying is a viable option for ensuring that our client receives its messages in the end for a number of the throttling conditions. This is the situation in any circumstance where time can assist with settling the issue.

The fix could be the result of messages being retrieved, connections being closed, or the number of clients decreasing. Nonetheless, it is critical to take note of that retries won’t help for this multitude of choking conditions. For instance, if a message is too large, retrying it will never be successful. As a result, when catching these exceptions, it’s critical to examine the actual exception. You can decide what to do next, depending on the kind of message.

Additionally, retries are scheduled to occur every ten seconds by default. Although this is acceptable in many situations, an exponential retry mechanism may be preferable. This mechanism tries again with a longer time interval, like 10 seconds, 30 seconds, 1 minute, and so on. With this mechanism, intermittent issues can be resolved quickly. But an exponential backoff retry mechanism also helps with long-term exceptions because it makes the time between tries longer. Monitoring A suitable monitoring strategy is essential when working with Service Bus. Utilizing a third-party product like Serverless360 or Azure’s built-in tooling are two ways to accomplish this. Each of these options has advantages and disadvantages.

Azure Monitor recently added new metrics that make it possible for us to observe the Service Bus throttling state. These capabilities, which provide a number of metrics for monitoring Service Bus namespaces and entities, are currently in preview. Throttled Requests is one of these metrics that tells us how many requests are throttled. After that, you can use Azure Monitor to create alerts that are based on these metrics. For this scenario, add an alert rule. When alerts are triggered and what actions are taken are defined by these rules.

These actions can be anything from sending an SMS or email to calling webhooks or Logic Apps. We can start custom workflows, notify particular teams, create a ticket, and more with these last two options. Select an action group in the alert rule that includes one or more actions to accomplish this.

As a result, you can even create multiple action groups for various alert types. You can send service-specific alerts to the organization’s service owners here, as well as high-level alerts to the operations team.

For Azure service bus monitoring and raising alerts for Service Bus Throttling conditions, Serverless360 provides simple configuration and notification options. In conclusion, monitoring the capabilities is always essential when establishing an architecture using Azure services. We investigate Service Bus throttling conditions in this instance. Most of the time, we mitigate by changing some of our clients’ properties or using a retry strategy. Additionally, a monitoring strategy tailored to our circumstance must be implemented in order to maintain clear insights into our environment. Where cautions are set off in the event that any of these choking conditions happen.