4

I am writing a utility to monitor our Azure Service Bus Topics and Subscriptions.

I can get the Topic details, such as name, queued message count and dead-letter message count, but I would like to get the number of messages that have been processed.

Here is the code I am using:

var sub = namespaceManager.GetSubscription(topicPath, subscriptionName);

var name = sub.Name;
var pending= sub.MessageCountDetails.ActiveMessageCount;
var deadletter = sub.MessageCountDetails.DeadLetterMessageCount

It seems that GetSubscription does not include any properties to get the number of messages processed.

Has anyone tried to do this before?

Thomas
  • 24,234
  • 6
  • 81
  • 125
Karl Gjertsen
  • 4,690
  • 8
  • 41
  • 64
  • Do you process your messages from a webjob or a worker role ? – Thomas Jul 20 '16 at 11:32
  • There are a couple of different topics, read from different apps, so it is a mixture. I was hoping for a way to attach to the topics or subscriptions and receive a ping every time something passed through. – Karl Gjertsen Jul 20 '16 at 12:03
  • 1
    I used Azure AppInsights to monitor my servicebus. You'll have to manually send events to App Insights but you will have cool dashboards. could be a solution for you ? I can post some code if you are interested in. – Thomas Jul 20 '16 at 12:37
  • @Thomas that could work. Any code, or a GitHub link, would be appreciated. – Karl Gjertsen Jul 20 '16 at 14:20
  • You can also use tools like CloudMonix to monitor message counts, deadletters, message rates, etc all in one UI without needing to code and maintain any tools.. http://www.cloudmonix.com – Igorek Jul 02 '18 at 20:21

3 Answers3

3

To get messages stats from Azure Servicebus entities, I use Visual Studio App Insights. This is a tool to monitor apps. Basically, your app sends events to App Insights and from the Azure Portal, you can create dashboards that give you real-time information on your app.

To monitor Azure Servicebus entities, I send custom events from my app:

  • You can have a look at the pricing, there is a free plan that allow you to send up to 5 millions of custom events per month. If you need to send more than 5 millions events, you can create an App Insights per Servicebus entity or aggregate count before sending events to App Insights.
  • You have access to your the raw data for 7 days and aggregate data for 90 days.

  • If you use Power BI, you can configure a continuous export of your data (don't think it is available in the free plan).

  • Other cool thing, you can send exceptions and create alert from App Insigths that send you an email any time exceptions are received to App Insigths.

If you process servicebus messages from a webjob/worker role/console app/windows service, this article could be a god starting point :

So after creating an App Insights from the Azure portal, you will get an InstrumentationKey.

You can install ApplicationInsights from nuget.

To send event to App Insights, you need to instantiate a TelemetryClient. Microsoft recommands to only have once instance of the telemetry client per app and to flush the TelemetryClient when the app stops or restarts:

var telemetryClient = new TelemetryClient()
    { InstrumentationKey = "MyInstrumentationKey" };

So this is a very basic example but you'll get the point:

// Get the message
BrokeredMessage message = ...

try
{
    // Process you message
    ...

    // Delete the message from the queue when it is ok.
    message.Complete();

    // Create and send an event to app insights
    var eventTelemetry = new EventTelemetry { Name = "MyQueueName" };
    eventTelemetry.Metrics["MessageCount"] = 1;
    telemetryClient.TrackEvent(eventTelemetry);
}
catch (Exception ex)
{
    // Send back the message to the queue ??? depends if you'd like to re-process it
    message.Abandon();

    // Send the exception to app insights
    telemetryClient.TrackException(ex);
}

Using this code, you will have a new event in App Insights with name MyQueueName. You can create a dashboard and filter on this event and display the MessageCount metric. I use a metric because in more complex scenario, you can just send one event every x minutes and set the MessageCount to the number of messages processed in this interval.

Here I am using App insights but I am pretty sure you can do the same with other tools like :

Hope this will help you !

Thomas
  • 24,234
  • 6
  • 81
  • 125
1

It is possible to fetch the Total Count of Messages in a Topic, Incoming Messages, Outgoing Messages with the help of the latest Azure Monitor Metrics. In your case, count of Outgoing messages will be the number of processed messages.

Arunprabhu
  • 1,454
  • 9
  • 15
  • 1
    I had to wait a while, but the technology caught up! – Karl Gjertsen Jun 29 '18 at 10:02
  • 2
    @KarlGjertsen, do consider the billing for accessing the metrics before integrating it with your solution. https://blogs.msdn.microsoft.com/servicebus/2018/02/09/azure-service-bus-billing-vs-metrics-vs-current-monthly-cost/ – Arunprabhu Jul 02 '18 at 11:31
0

Number of processed messages since creation of the entity? Or from a certain date? And what about messages that have been processed multiple times (delivery count > 1) because the client failed to complete on time or some other reasons? This count is not straight forward and that's why is not available out of the box.

Sean Feldman
  • 23,443
  • 7
  • 55
  • 80
  • Yeah, I guessed that was the reason. Your answer doesn't mention how to do this though. Any ideas? – Karl Gjertsen Jul 20 '16 at 07:28
  • I'd think that if your application is interested in this info, it would be responsible for the logic. You'd have to consider retries, scale out, etc. This is not broker responsibility. – Sean Feldman Jul 20 '16 at 07:35
  • Agreed. But how would a standalone application monitor this? Is there a way to add a listener? – Karl Gjertsen Jul 20 '16 at 07:42
  • Application would count those messages. Broker has no way to provide an accurate count. – Sean Feldman Jul 20 '16 at 07:53
  • I don't think that is true. I have seen an application that can monitor the queues, but I'm not sure how to do it. Thanks for the comments though. Just hope someone else knows how to do this. – Karl Gjertsen Jul 20 '16 at 08:46
  • As you can see, there's no native support. It's application concern, not ASB broker. – Sean Feldman Jul 21 '16 at 19:53
  • Seems like a big oversight that the details are not stored for a defined period. – Karl Gjertsen Jul 21 '16 at 22:19
  • It's a problematic feature once you think about it. Lifetime counter makes little sense. Anything else is a subject to errors due to the nature of broker. Processing is done on the client side, so only the app can know when message is "done-done". And even then, there can be challenged. Just by issuing the complete command on s brokered message doesn't mean the message will be completed on the broker (connectivity issue or dinner failure can cause it to fail). Rate, but can happen. You can raise a feature request here: https://feedback.azure.com/forums/216926-service-bus – Sean Feldman Jul 22 '16 at 05:35
  • [This page](https://msdn.microsoft.com/en-us/library/azure/dn163586.aspx) describes REST API to get Service Bus metrics including Incoming messages per interval. So I guess, the metrics do exist. – Mikhail Shilkov Sep 09 '16 at 15:01