System types · Built-in All levels

Azure Service Bus

The built-in Azure Service Bus system type — detection prefixes, the community Collector receiver that produces the metrics, starter checks for dead-letters and backlog per queue and subscription, and tuning notes.

SLSluicio team 4 min read Updated Jul 2026

Azure Service Bus is Microsoft’s managed message broker — queues for point-to-point, topics with subscriptions for publish-subscribe. Being managed, there’s no broker host to watch; what matters is the message flow: backlogs building on queues and subscriptions, and messages landing in dead-letter queues — Service Bus’s parking lot for messages that expired, exceeded delivery attempts, or were dead-lettered by your code. This system type watches both, split per entity.

Key: azure-servicebus · applied automatically to services emitting servicebus.-prefixed metrics.

Getting the telemetry

There’s no Service Bus receiver in the stock Collector distributions — you build a small custom Collector bundling the community azureservicebusreceiver (Integrio, metrics-only). Once built, the config is ordinary:

receivers:
  azureservicebus:
    namespace_fqdn: yournamespace.servicebus.windows.net
    collection_interval: 60s

The full walkthrough — building the Collector with ocb, authenticating with a managed identity or service principal, the export pipeline to Sluicio — is in Monitor Azure Service Bus.

What Sluicio detects

Metrics whose names start with servicebus. — servicebus.queue.active_messages, servicebus.queue.deadletter_messages, servicebus.topic.subscription.active_messages, and friends. Queue metrics carry a queue attribute; subscription metrics carry topic and subscription.

Starter checks

Check	Condition	Severity	Why it matters
Dead-lettered messages (queue)	`servicebus.queue.deadletter_messages` > 0, split by queue	Warning	A dead letter means a message left the flow — expired, poisoned, or exceeded max deliveries. The DLQ should be near-empty.
Dead-lettered messages (subscription)	`servicebus.topic.subscription.deadletter_messages` > 0, split by topic and subscription	Warning	Same failure shape on the pub-sub side — one broken subscriber dead-letters silently while the others keep up.
Queue backlog	`servicebus.queue.active_messages` > 5,000, split by queue	Warning	Active messages accumulating means receivers aren’t keeping up.
Subscription backlog	`servicebus.topic.subscription.active_messages` > 5,000, split by topic and subscription	Warning	Per-subscription backlog pinpoints which subscriber is behind, not just that the topic is busy.

Tuning notes

Dead-letter checks fire on presence, not growth. > 0 is deliberately strict — a healthy entity has an empty DLQ. If you keep messages parked in a DLQ on purpose (manual replay workflows), raise the threshold on those entities or the check becomes a standing alarm.
Backlog thresholds are per-entity decisions: 5,000 is a starting point, not a truth. Because the checks split by queue / subscription, you can keep the default globally and tighten it only on latency-sensitive entities.
The receiver’s collection_interval bounds your detection latency — at 60s, expect up to a minute before a dead letter shows up. Shorten it if that matters, mindful of the metadata-read cost against the namespace.