When Enterprise applications communicate with each other by sending and receiving messages through Azure Service Bus Queue instead of direct API calls, it’s necessary to keep an eye on the availability of the Queue and its length to make sure the system functions properly.
Let us take an example of a retail application architecture in which the customer placed an order from its shopping website (sender). Then the request message is sent to a Service Bus Queue and remains there until the inventory management system (Receiver) retrieves the message and processes it. There may be a situation where the messages are not being read due to unavailability of the receiver due to receiver system shutdown or crash. In these cases, the messages get piled up in the Queue. If the messages are retained in the Queue for a long time without being received, they will get expired once Time To Live is elapsed and at last, the retailer loses the order.
Note: Once a message is expired, it will automatically be moved to the dead-letter queue, that is if EnableDeadLetteringOnMessageExpiration is enabled.
ServiceBus360 helps to keep an eye on the infrastructure by offering the out of box monitoring capabilities to monitor the Azure Service Bus Queues and other resources. We can overcome the above problem by creating an alarm and monitor the Service Bus Queue properties. ServiceBus360 monitors and sends notifications through email.
Scenario 1: Monitoring an Azure Service Bus Queue for message count beyond expected limits
Enterprise applications use Azure Service Bus Queue for messaging on a daily basis, some of the queues that are used for constant messaging may hit a backlog of heavy message count indicating a bottleneck somewhere. Either there is an outburst of messages from the Senders or the Receivers are not consuming the messages at the expected rate. We may need to monitor this situation and be vigilant.
The solution for this problem is very straight forward, we can create threshold alarm and associate the queue to alarm for monitoring. We have to configure the Error and Warning threshold condition to receive notifications if the Queue size breaches the given condition.
We can also monitor other properties of the Azure Service Bus Queue like:
- Active Message count
- DeadLetter Message count
- Message count
- Schedule Message count
- Transfer DeadLetter Message count
- Transfer Message count
Based on the configuration, the Azure Service Bus Queue will be monitored and results are represented in Monitoring Dashboard.
We get an email notification with necessary details based on the alarm configuration.
Scenario 2: Monitoring Azure Service Bus Queue for expected behavior between certain time window
Most of the enterprises use a wide range of business applications such as CRM, SAP etc. Consider a marketing enterprise using a Queue for messaging and all the sales representatives have to submit their reports on a weekly basis on Friday between their reporting hours (12:00 PM-1:00 PM). The Project Manager expects a huge influx of messages says at least 5K messages as a weekly target.
In this case, he can monitor this by creating an alarm with “restrict the threshold violation alerts” configuration by selecting Set alert on set day and time only checkbox. Then set the day on Friday and start and end time as between 12:00 PM to 01:00 PM.
The queue is monitored for the minimum number of messages that should have arrived based on the report submission. This monitoring will be enabled only between the configured timelines. If the threshold conditions are breached within the configure time window, then email notification will be sent.
Try ServiceBus360 for free!
With the lifetime free account of ServiceBus360, you can monitor 1 Messaging Namespace, 1 Relay Namespace, 1 Event Hub Namespace, and monitor up to 2 entities in a namespace. You can also check out the Pricing page for details on Professional plans (monthly and annual).
Watch our video on Service Bus Queue Monitoring.