Monitoring Service Bus: Metrics, Alarms, and Dashboards

Understanding Service Bus Monitoring

Azure Service Bus (or any cloud messaging service) is a critical backbone for distributed applications. Without proper monitoring, message backlogs, throttling, or dead-letter accumulation can cause cascading failures. This tutorial covers how to monitor Service Bus effectively using metrics, alarms, and dashboards, with practical code examples you can run in your own environment.

What is Service Bus Monitoring?

Monitoring Service Bus involves collecting telemetry data about the service’s performance, health, and message flow. This data comes in the form of metrics—numerical values measured over time—such as the number of active messages, incoming requests, and throttled operations. By analyzing these metrics, you can detect anomalies, plan capacity, and troubleshoot issues.

Why Monitoring Matters

Prevent data loss: Dead-letter queues can overflow if not monitored, leading to lost messages.
Avoid throttling: Service Bus has quotas on namespace and entity level. Monitoring request rate and throttle metrics helps you scale before hitting limits.
Optimize performance: Track message delivery latency, completion rate, and errors to identify bottlenecks in your consumers.
Cost management: Pay attention to metrics like message count and operations to avoid unexpected billing spikes.
Compliance and SLA: Ensure your messaging system meets uptime and processing guarantees with proactive alarms.

Key Metrics to Track

Azure Service Bus exposes a rich set of metrics through Azure Monitor. Below are the most critical ones you should monitor, along with their meaning and typical thresholds.

Message Count Metrics

Active Messages: The number of messages available in a queue or topic subscription ready for delivery. A rising count indicates slow consumers or a publisher spike.
Dead-lettered Messages: Messages that exceeded max delivery count or expired. A non-zero value requires immediate investigation.
Size of Queue/Topic (bytes): The total size of all messages. Approaching the entity limit triggers throttling.

Throughput and Performance Metrics

Incoming Requests: The number of message send operations per time unit. Helps detect publisher anomalies.
Outgoing Requests: The number of message receive/complete operations. Shows consumer throughput.
Throttled Requests: Requests that were rejected because the namespace or entity quota was exceeded. This is a critical alarm trigger.
Server Errors / User Errors: Failures returned by the Service Bus service. Distinguish between client-side (user) and service-side errors.

Connection and Session Metrics

Active Connections: Number of open AMQP connections. Helps identify connection leaks or client scaling.
Active Sessions: For session-enabled entities, the number of active sessions.

You can retrieve these metrics via Azure Portal, CLI, PowerShell, or REST API. The following example shows how to list available metrics for a Service Bus namespace using Azure CLI.

# List metric definitions for a Service Bus namespace
az monitor metrics list-definitions \
  --resource "/subscriptions/{subscriptionId}/resourceGroups/{rg}/providers/Microsoft.ServiceBus/namespaces/{namespace}" \
  --output table

Setting Up Alarms

Alarms (metric alerts) proactively notify you when a metric crosses a defined threshold. For Service Bus, you can create alerts based on static thresholds or dynamic (machine-learning-based) thresholds. Alarms can trigger actions like sending emails, SMS, webhook calls to PagerDuty, or running automated remediation scripts via Azure Functions.

Choosing Alert Thresholds

Dead-letter queue non-zero: Alert immediately when the dead-letter message count is greater than 0 for 5 minutes.
Queue depth approaching quota: Alert when active message count exceeds 80% of the maximum entity size (e.g., for a queue with max size 1 GB, alert if size > 800 MB).
Throttled requests > 0: Alert when any request is throttled, indicating a need to scale up or review usage.
Server errors spike: Alert if server error rate exceeds a baseline (e.g., > 1% of total requests).
Low consumer throughput: Alert if outgoing requests drop below expected baseline during business hours.

Creating a Metric Alert with Azure CLI

The following snippet creates a static threshold alert on dead-letter message count for a specific queue. It will send an email to the specified address via an existing action group.

# Create an alert rule for dead-letter messages on queue "orders"
az monitor metrics alert create \
  --name "DeadLetterQueue-Alert-orders" \
  --resource-group "myResourceGroup" \
  --scopes "/subscriptions/.../resourceGroups/myResourceGroup/providers/Microsoft.ServiceBus/namespaces/myNamespace/queues/orders" \
  --condition "Dead-lettered messages > 0" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --action-group "/subscriptions/.../resourceGroups/myResourceGroup/providers/microsoft.insights/actionGroups/myActionGroup" \
  --description "Alert when dead-letter messages appear in orders queue"

Dynamic Threshold Alerts (Machine Learning)

Dynamic thresholds are useful for metrics with natural variability (e.g., incoming requests). Azure Monitor learns the typical pattern and alerts on deviations. Example using CLI:

az monitor metrics alert create \
  --name "ThrottledRequests-DynamicAlert" \
  --resource-group "myResourceGroup" \
  --scopes "/subscriptions/.../resourceGroups/myResourceGroup/providers/Microsoft.ServiceBus/namespaces/myNamespace" \
  --condition "Throttled Requests > dynamic" \
  --window-size 15m \
  --evaluation-frequency 5m \
  --action-group "/subscriptions/.../resourceGroups/myResourceGroup/providers/microsoft.insights/actionGroups/myActionGroup" \
  --description "Dynamic alert on throttled requests"

Note: For dynamic thresholds, the condition uses " > dynamic" and Azure automatically determines the threshold based on recent history.

Programmatic Alert Creation (ARM Template / Bicep)

For infrastructure-as-code, you can define alerts in ARM templates or Bicep. Here’s a Bicep snippet for a dead-letter alert:

resource deadLetterAlert 'Microsoft.Insights/metricAlerts@2021-09-01-preview' = {
  name: 'dead-letter-orders-queue-alert'
  location: 'global'
  properties: {
    description: 'Alert on dead-letter messages in orders queue'
    severity: 2
    enabled: true
    evaluationFrequency: 'PT1M'
    windowSize: 'PT5M'
    scopes: [
      {
        id: queue.id // reference to the queue resource
      }
    ]
    criteria: {
      'odata.type': 'Microsoft.Azure.Monitor.SingleResourceMultipleMetricCriteria'
      allOf: [
        {
          name: 'Metric1'
          metricName: 'Dead-lettered Messages'
          metricNamespace: 'Microsoft.ServiceBus/namespaces'
          operator: 'GreaterThan'
          threshold: 0
          timeAggregation: 'Average'
          dimensions: []
        }
      ]
    }
    actions: [
      {
        actionGroupId: actionGroup.id
      }
    ]
  }
}

Building Dashboards

Dashboards provide a centralized visual overview of Service Bus health. You can build dashboards in Azure Portal, Grafana, or Power BI. The goal is to surface the most important metrics at a glance and allow drill-down into specific queues or topics.

Azure Portal Custom Dashboards

The Azure Portal allows you to pin metric charts from individual resources to a shared dashboard. To create a dashboard for Service Bus:

Go to your Service Bus namespace in the portal.
Under Monitoring, select “Metrics”.
Choose a metric like “Active Messages” and aggregation “Average”.
Apply a filter to split by entity (queue/topic) to show a multi-line chart.
Click “Pin to dashboard” and select an existing dashboard or create new.
Repeat for other key metrics: Dead-lettered Messages, Throttled Requests, Server Errors.

You can also create workbooks with richer visualizations and queries. Here's an example Kusto query for a workbook that shows top queues by active message count:

// Kusto query for Service Bus metrics in Log Analytics (requires diagnostic settings)
AzureMetrics
| where ResourceProvider == "MICROSOFT.SERVICEBUS"
| where MetricName == "ActiveMessages"
| where TimeGenerated > ago(1h)
| summarize AvgActive = avg(Total) by bin(TimeGenerated, 5m), EntityName = tostring(Split(Resource, "/")[10])
| render timechart

Grafana Dashboard with Azure Monitor Data Source

If you use Grafana, you can connect it to Azure Monitor. Install the Azure Monitor data source plugin, then create a dashboard with panels for:

Queue depth (Active Messages) per queue – use a bar gauge or time series.
Dead-letter count per subscription – a stat panel with threshold colors.
Throttled request rate – a graph panel with alert thresholds.
Namespace incoming/outgoing request rate – stacked area chart.

Example Grafana JSON model for a panel querying Azure Monitor for active messages:

{
  "subscriptionId": "xxxx-xxxx-xxxx",
  "query": "AzureMetrics | where ResourceProvider == 'MICROSOFT.SERVICEBUS' and MetricName == 'ActiveMessages' | summarize AvgActive = avg(Total) by bin(TimeGenerated, 5m), EntityName",
  "resultFormat": "time_series",
  "azureMonitor": {
    "aggregation": "Average",
    "metricName": "ActiveMessages",
    "metricNamespace": "Microsoft.ServiceBus/namespaces",
    "resourceGroup": "myResourceGroup",
    "resourceName": "myNamespace",
    "timeGrain": "PT5M"
  }
}

You can also use Azure Monitor metrics directly via the Azure Monitor Grafana data source without Log Analytics, using the “Azure Monitor” service query type.

Automating Dashboard Creation with Terraform or Azure CLI

You can define dashboards as code using the Azure Dashboard resource or Terraform. The following Azure CLI command creates a basic dashboard with pinned tiles for active messages and dead-letter messages (simplified example).

az portal dashboard create \
  --name "ServiceBus-Health-Dashboard" \
  --resource-group "myResourceGroup" \
  --location "westus" \
  --tags "environment=production" "team=platform" \
  --definition '{
    "lenses": {
      "0": {
        "order": 0,
        "parts": {
          "0": {
            "position": { "x": 0, "y": 0, "rowSpan": 4, "colSpan": 6 },
            "metadata": {
              "inputs": [],
              "type": "Extension/Microsoft_Azure_Monitoring/PartType/MetricsChartPart",
              "settings": {},
              "asset": {
                "id": "/subscriptions/.../resourceGroups/myResourceGroup/providers/Microsoft.ServiceBus/namespaces/myNamespace",
                "metric": "ActiveMessages"
              }
            }
          }
        }
      }
    }
  }'

Note: Full dashboard JSON is complex; consider using the portal's export feature to get the definition, then parameterize it.

Best Practices

1. Enable Diagnostic Settings

Send Service Bus metrics and logs to Log Analytics, Storage, or Event Hub. This enables advanced querying and longer retention. Without diagnostic settings, you only get the default 30-day portal metrics.

az monitor diagnostic-settings create \
  --resource "/subscriptions/.../resourceGroups/myResourceGroup/providers/Microsoft.ServiceBus/namespaces/myNamespace" \
  --name "send-to-log-analytics" \
  --workspace "/subscriptions/.../resourceGroups/myResourceGroup/providers/Microsoft.OperationalInsights/workspaces/myWorkspace" \
  --logs '[{"category": "AdministrativeLogs", "enabled": true}, {"category": "OperationalLogs", "enabled": true}]' \
  --metrics '[{"category": "AllMetrics", "enabled": true}]'

2. Use Multi-Dimensional Alerts

Instead of creating a separate alert for each queue, use dimension filters. For example, create a single alert on “Active Messages” with a dimension filter for entity name, and dynamically add new queues as they are created (if using auto-scaling).

3. Set Alarms at Different Severities

Not all issues require immediate pager alerts. Use Sev 0 for dead-letter > 0 or throttling > 0. Use Sev 2 for queue depth > 60% for early warning. Sev 3 for informational like active connections spike.

4. Correlate Metrics with Application Logs

Combine Service Bus metrics with application telemetry (e.g., via Application Insights). For instance, if dead-letter messages increase, also query application logs for exceptions during processing.

5. Implement Automated Remediation

For alarms that indicate clear fixes (e.g., throttling), use Azure Functions or Logic Apps to scale the namespace or clear dead-letter messages automatically (after safe re-processing logic).

6. Review and Adjust Thresholds Regularly

As your traffic patterns change, adjust alert thresholds. Use dynamic alerts where appropriate to reduce noise.

7. Maintain Dashboard as Code

Keep your dashboards in version control using Terraform or Azure CLI scripts. This allows you to replicate across environments (dev, staging, prod) and track changes.

8. Monitor Namespace and Entity Quotas

Azure Service Bus has limits on namespace connections, entity count, and message size. Use Azure Advisor or custom alerts on quota metrics to avoid hitting hard limits.

9. Use Service Health Alerts

Monitor the overall Azure Service Bus service health in your region. Combine service health alerts with your metric alerts to distinguish platform issues from your own application problems.

Conclusion

Effective monitoring of Service Bus is not just about collecting data; it’s about translating that data into actionable insights. By tracking the right metrics, configuring intelligent alarms, and building comprehensive dashboards, you can ensure your messaging infrastructure remains reliable, scalable, and cost-efficient. Start with the basics—dead-letter and throttling alerts—then expand to a full observability stack integrated with your DevOps workflows. Remember to treat your monitoring configuration as code, enabling consistency across environments and continuous improvement.