Azure Service Bus

Monitoring

How to ensure ASB systems are working properly

Azure Service Bus is a cloud-based messaging service that enables reliable communication between applications and services, even when some of them are temporarily unavailable. Azure Service Bus queues and topics are often used to decouple parts of connected systems and to offload heavy-duty processing to background tasks. Loose coupling improves the overall reliability and performance of the system. However, with a level of abstraction offered by the Service Bus, it is harder to notice when message processing fails or doesn’t keep up with the demand.

This use case covers metrics that should be monitored in systems using Azure Service Bus queues and topics and how they can be configured in CloudMonix. There are 4 main points to consider to ensure ASB systems are working properly:

1. Ensure that messages are being enqueued

Knowing that messages are being enqueued is important to ensure the ASB is working properly. CloudMonix allows ensuring this process is performed without errors by monitoring the incoming messages per the defined time grain and alerting immediately on any messages not being enqueued. To learn more about this process read below >

2. Ensure that messages are being picked up

It is also important to validate that message processors are working and are actually picking up messages. CloudMonix does this by monitoring the outgoing messages and fires an immediate alert on messages not being picked up. For further details on the outgoing messages monitoring read below >

3. Ensure that messages are not erroring out

Upon several unsuccessful attempts to process a message, Azure Service Bus will mark such message as a dead letter to ensure it does not poison queues and topics. CloudMonix provides metrics and alerts that will allow you to be immediately aware of any dead-letters in your queues and topics. To learn more on how to ensure messages are not in the dead-letter queue read below >

4. Ensure that messages are dequeued quickly enough

The last step is to validate that message processors are actually dequeuing messages. CloudMonix does this by monitoring the change in the ID of the message to be processed next. When no change in the ID occurs CloudMonix detects the message is stuck in the queue and fires an alert. For further information on the dequeuing process read below >

How to ensure that messages are being enqueued

In order to ensure that messages are coming into Azure Service Bus queue, the following needs to be implemented:

  • track “Incoming Messages” metric;
  • alert when that metric equals to 0

How to ensure that messages are being picked up

Implement the following to track the messages are getting depleted:

  • track “Outgoing Messages” metric;
  • alert when that metric equals to 0
CloudMonix - proactive reboots

How to ensure that messages are not erroring out

In order to track any of the dead-letter queues or topics:

  • track “Queues” metric (enabled by default);
  • alert when the number of dead-letters is greater than 0
CloudMonix - proactive reboots
CloudMonix - proactive reboots

How to ensure that messages are dequeued quickly enough

The following configuration will track that messages are dequeued in time:

  • define and track the metric of type “AzureServiceBusOldestMessageId”;
  • define and track the metric of type “AggregateMetric” with the “PreviousValue” aggregation method and the period of over 5 minutes;
  • alert when the current and previous oldest messages are identical
CloudMonix - proactive reboots
CloudMonix - proactive reboots

Apart from monitoring and automatic notifications, CloudMonix also offers powerful automation. For example, you can auto-scale Cloud Services and Web Apps based on ASB queues lengths. Learn more >