Monitoring RabbitMQ, Kafka, and ActiveMQ: The Engineer’s Handbook (2026)

Monitoring RabbitMQ, Kafka, and ActiveMQ is harder than basic uptime checks because each broker fails in a different way. Most messaging broker incidents build up before they become visible. By the time an alert fires, the issue may already be affecting producers, consumers, or downstream services.

The harder problem is that RabbitMQ, Kafka, and ActiveMQ have different architectures and different failure modes. A monitoring setup built for one does not transfer to the others. Queue depth is a critical signal in RabbitMQ. In Kafka, it tells you almost nothing, because consumers pull at their own pace and the broker has no opinion on whether they are keeping up.

This handbook breaks down the metrics, alerts, dashboards, and setup steps engineers need to monitor RabbitMQ, Kafka, and ActiveMQ in 2026. 

Why Message Broker Monitoring Matters in 2026

Three changes in the last two years make existing monitoring setups worth revisiting.

Apache Kafka 4.0, released March 2025, removed ZooKeeper entirely. KRaft is now the only supported coordination mode. Any runbook referencing ZooKeeper connection counts or session errors is obsolete.

RabbitMQ also changed the metadata-store path. Khepri became fully supported in RabbitMQ 4.0 and became the default backend in RabbitMQ 4.2, while upgraded clusters may still run on Mnesia unless Khepri is enabled. That means teams need to know which metadata store their cluster is actually using before trusting old dashboards.

ActiveMQ is still widely used, but its PeerSpot user-engagement mindshare fell from 26.4% to 19.8% by May 2026. Many teams now run ActiveMQ alongside Artemis, Kafka, or other brokers during migrations, which creates separate JMX namespaces, different metrics, and more monitoring work.

Quick Reference: Architecture and Monitoring Interface by Broker

Each broker has a distinct failure profile. That profile determines which metrics are worth alerting on.

Monitoring RabbitMQ: The Complete 2026 Guide

RabbitMQ is a push-based broker. Producers send to exchanges, exchanges route into queues, and the broker pushes messages to consumers.

The failure mode that ends most RabbitMQ incidents is resource exhaustion. Once memory or disk thresholds are breached, RabbitMQ activates flow control and stops accepting new publishes across all connections. Producers are blocked before you know about it.

Effective RabbitMQ monitoring means watching resource levels and queue states well before they reach alarm territory.

Critical RabbitMQ Metrics

Queue Depth and Message States

Queue depth is the most actionable signal in RabbitMQ. Messages are in one of three states at any moment:

• Ready: waiting to be delivered to a consumer
• Unacknowledged: delivered but not yet acknowledged, meaning the consumer is still processing
• Total: the sum of both

The split between ready and unacknowledged messages is often more useful than the total queue depth. If unacknowledged messages keep rising while throughput stays flat, consumers may be stuck, slow, or failing to acknowledge messages. If ready messages keep building while unacknowledged stays at zero, the queue may have no active consumers, or consumers may not be receiving messages.

Memory and Disk Alarms

RabbitMQ blocks all publishing connections when memory hits 40% of total system RAM by default. The disk alarm fires when free disk falls below 50 MB. Both are configurable. Monitor via the HTTP Management API at /api/nodes or the Prometheus endpoint:

• rabbitmq_process_resident_memory_bytes: raw memory consumption
• rabbitmq_disk_space_available_bytes: free disk remaining
• rabbitmq_alarms_memory_used_watermark: 1 when the memory alarm is active. Page immediately.
• rabbitmq_alarms_free_disk_space_watermark: 1 when the disk alarm is active

Connection and Channel Churn

Every RabbitMQ connection consumes an Erlang process and an OS file descriptor. Applications that open connections per request rather than pooling them will eventually exhaust both.

• rabbitmq_connections: total open connections
• rabbitmq_channels: total open channels, should scale proportionally with connections
• rabbitmq_connection_created_total: rate of new connections. A sudden spike almost always indicates a reconnection storm from a brief network partition or broker restart

Consumer Utilisation

Consumer utilisation measures what fraction of its time a consumer is actually active. A value of 1.0 means always busy. A value of 0.3 means idle 70% of the time, which usually points to a low prefetch count or a slow processing function.

Available per-queue through the Management API. Track it on any queue where depth is growing despite consumers being present.

Message Rates

• rabbitmq_queue_messages_published_total: messages published per queue
• rabbitmq_queue_messages_delivered_total: messages delivered to consumers
• rabbitmq_queue_messages_redelivered_total: redeliveries. A rising rate points to a consumer-side processing bug, not a capacity problem

Setting Up Prometheus and Grafana for RabbitMQ

RabbitMQ ships a native Prometheus plugin since version 3.8. One command enables it:

rabbitmq-plugins enable rabbitmq_prometheus

rabbitmq-plugins enable rabbitmq_prometheus

Metrics are available at http://<node>:15692/metrics. Add a Prometheus scrape job and import Grafana Dashboard ID 10991 as a starting point. 

The HTTP Management API

The Management API at port 15672 exposes full broker state in JSON. Most useful endpoints: /api/overview for a cluster summary, /api/queues for per-queue state and consumer details, /api/nodes for per-node memory and file descriptor usage.

Use the API for investigation. Use Prometheus scraping for alerting.

Alerting Thresholds

Security Monitoring for RabbitMQ

RabbitMQ’s native audit logs capture basic user actions but lack filtering and correlation. Supplement them:

• Enable rabbitmq_auth_backend_ldap and alert on failed LDAP bind attempts
• Track connection creation rate by source IP. A spike from a single IP on port 5672 is usually credential stuffing or a misconfigured reconnect loop
• RabbitMQ supports OAuth 2.0 natively. Monitor token expiry and forced disconnections; both look like ordinary consumer churn until you check the reason codes
• Alert on any new virtual host created in production. It is a rare event outside deployment pipelines
• Monitor TLS handshake failures. A spike usually means a client certificate misconfiguration or a port scanner

Monitoring Apache Kafka: Consumer Lag, Partition Health, and KRaft

Kafka has a different operating model from RabbitMQ. Producers write records to topic partitions, while consumers read those partitions at their own pace and track progress through offsets.

That makes consumer lag one of the first Kafka signals to watch. If a consumer group stops keeping up, the broker will continue accepting writes, but downstream services may start working with delayed data long before the issue is visible to users.

Critical Kafka Metrics

Consumer Lag

Consumer lag is the gap between the latest offset written to a partition and the offset a consumer group has committed.

Lag = Log End Offset - Current Committed Offset

Lag = Log End Offset - Current Committed Offset

Steady growth means consumer throughput is consistently below producer throughput. A spike that recovers is usually transient: a slow batch, a GC pause, a brief dependency blip.

Track per consumer group and per partition using:

• JMX: kafka.consumer:type=consumer-fetch-manager-metrics,client-id=*,topic=*,partition=*,name=records-lag
• Burrow (https://github.com/linkedin/Burrow): evaluates lag trends over time rather than absolute values, significantly reducing false positives from normal traffic variability
• kafka_exporter (https://github.com/danielqsj/kafka_exporter): exposes per-group per-partition lag as Prometheus metrics, which the JMX Exporter alone does not provide

Under-Replicated Partitions

Under-replicated partitions are the most urgent broker health signal in Kafka. A partition is under-replicated when one or more in-sync replicas has fallen behind the leader. The effective replication factor drops. A broker failure at that point risks data loss.

The main signal to monitor is:

• JMX: kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions
• Target: 0 at all times
• Common causes: disk I/O pressure on a broker, a recently restarted broker still catching up, or a network partition between brokers

Active Controller Count

Exactly one broker should hold the controller role at any time. The controller manages partition leadership and handles broker failures.

Use this metric to confirm controller health:

• JMX: kafka.controller:type=KafkaController,name=ActiveControllerCount
• Value of 0: no controller elected. The cluster cannot reassign partition leadership
• Value greater than 1: split-brain condition requiring immediate intervention

Broker Throughput

The core throughput metrics are:

• kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec: incoming byte rate
• kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec: outgoing byte rate
• kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec: message ingestion rate

A drop in BytesInPerSec without a matching drop in producer activity signals a partition leadership problem. A spike in BytesOutPerSec without a corresponding business event usually means a consumer is replaying from an older offset.

Request Latency

Start with these request metrics:

• kafka.network:type=RequestMetrics,name=TotalTimeMs,request=Produce: end-to-end produce latency
• kafka.network:type=RequestMetrics,name=TotalTimeMs,request=FetchConsumer: consumer fetch latency
• For acks=all with three-way replication on healthy hardware, a realistic p99 baseline is 100 to 300 ms. Above 500 ms warrants investigation

KRaft-Specific Metrics (Kafka 4.0 and Later)

Useful KRaft-specific metrics include:

With ZooKeeper removed in Kafka 4.0, these replace the old ZooKeeper health checks:

• kafka.controller:type=MetadataManager,name=LastAppliedRecordOffset: how far each controller has applied the metadata log. A growing gap indicates a stressed controller quorum
• kafka.controller:type=ControllerMetrics,name=EventQueueTimeMs: how long events wait before the controller processes them. Elevated values mean the controller is overloaded

Setting Up JMX to Prometheus for Kafka

Kafka exposes broker metrics through JMX, so the usual setup is to run the Prometheus JMX Exporter as a Java agent with each broker JVM. The exporter opens an HTTP endpoint that Prometheus can scrape. Use a Kafka-specific rules file instead of exposing every MBean, otherwise the metric set can become noisy and hard to manage.

Consumer lag needs separate treatment. The JMX Exporter can expose broker and JVM metrics, but group-level lag is usually easier to monitor with kafka_exporter or Burrow. These tools read consumer group offsets and expose lag in a form that works better for Prometheus alerts and Grafana dashboards.

For Amazon MSK, CloudWatch already includes broker and consumer-lag metrics, but the level of detail depends on the monitoring tier. DEFAULT gives basic cluster metrics, while PER_BROKER, PER_TOPIC_PER_BROKER, and PER_TOPIC_PER_PARTITION add more granular broker, topic, and partition-level visibility.

Alerting Thresholds

Security Monitoring for Kafka

Kafka supports SSL/TLS for encryption and SASL for authentication. Key signals:

• Failed authentication attempts via RequestMetrics for Authenticate requests. A spike usually means rotated or expired client credentials
• For SASL/OAUTHBEARER: token refresh failures. A consumer that cannot refresh stops consuming. The resulting lag looks identical to a slow consumer unless you are also tracking auth errors
• Connections per authenticated principal. An unfamiliar principal or a known one from an unexpected IP warrants a look
• AWS MSK Audit Logging and Confluent Platform both provide principal-level event tracking. Enable it and route logs to your SIEM

Monitoring Apache ActiveMQ: JVM Health, Blocked Producers, and Store Usage

ActiveMQ is a JMS-centric broker running on the JVM. Its failure modes are JVM heap exhaustion, KahaDB index corruption, and producers blocked by destination memory limits.

ActiveMQ Classic exposes everything through JMX. There is no native Prometheus endpoint without a third-party exporter.

Critical ActiveMQ Metrics

Setting Up Prometheus Monitoring for ActiveMQ

ActiveMQ Classic does not expose Prometheus metrics by default, so most teams use the Prometheus JMX Exporter.

A basic setup looks like this:

1. Run the JMX Exporter as a Java agent with the ActiveMQ JVM.
2. Use an ActiveMQ-specific rules file so you only collect the broker, destination, store, and JVM metrics you need.
3. Configure Prometheus to scrape the exporter endpoint.
4. Build alerts for memory usage, temp usage, store usage, queue depth, consumer count, and blocked producers.

The ActiveMQ Web Console at http://<host>:8161/admin is helpful during troubleshooting. It should not replace automated alerts, dashboards, or long-term metric storage.

ActiveMQ Classic vs Artemis: Monitoring Differences

Monitoring is one of the areas teams often underestimate during an ActiveMQ Classic to Artemis migration. Both brokers support JMX, but their metric names and management paths are different.

The main differences are:

• Classic uses the org.apache.activemq MBean namespace.
• Artemis uses the org.apache.activemq.artemis namespace.
• Classic advisory topics such as ActiveMQ.Advisory.* do not have a direct one-to-one replacement in Artemis.
• Dashboards, alert rules, and runbooks built for Classic usually need to be rebuilt for Artemis.

This does not mean Artemis is harder to monitor. It just means Classic monitoring should not be copied over unchanged.

Unified Observability: Monitoring All Three Brokers Together

Most production environments run more than one broker. Analytics on Kafka. Task queues on RabbitMQ. Legacy integrations on ActiveMQ.

The observability stack needs to cover all of them without creating separate silos that no one crosses during an incident.

6.1 Prometheus and Grafana

The standard open-source setup for 2026:

• RabbitMQ: enable the rabbitmq_prometheus plugin and scrape http://<node>:15692/metrics
• Kafka: deploy the JMX Exporter as a Java agent on each broker, and run kafka_exporter separately for consumer group lag
• ActiveMQ: deploy the JMX Exporter with an ActiveMQ-specific MBean rules file

Grafana Dashboard ID 10991 covers RabbitMQ. The Confluent community maintains Kafka dashboards. For ActiveMQ environments, meshIQ’s Infrared360 provides a unified console covering both Classic and Artemis.

OpenTelemetry for Distributed Tracing

Prometheus shows the broker-side symptoms. OpenTelemetry helps connect those symptoms to the producer, consumer, or downstream service involved.

Instrument producers and consumers with OpenTelemetry, then propagate trace context through message headers. This allows a trace to follow the path from message publish to broker interaction to consumer processing, instead of treating each service as a separate incident. OpenTelemetry’s messaging conventions are designed for this kind of producer-consumer workflow.

On the consumer side, one of the most useful signals is the time between message publication and processing start. It shows how long the message waited before a consumer picked it up, which is often the missing link between broker metrics and user-facing delay.

CubeAPM for Broker Monitoring

CubeAPM integrates with the Prometheus pipeline for all three brokers and adds:

• Correlated alerting: surface a consumer lag spike alongside the upstream service error rate that caused it
• Baseline-relative anomaly detection: alert when queue depth deviates from historical patterns rather than fixed thresholds, reducing false positives during expected traffic spikes
• Unified broker view: RabbitMQ, Kafka, and ActiveMQ side-by-side in one dashboard
• Trace-to-metric correlation: link OpenTelemetry spans to broker metric events without switching tools

Monitoring Tools Comparison for 2026

Alerting Best Practices

Alerting on raw metrics without context is how teams learn to ignore alerts. A RabbitMQ queue at 50,000 messages may be normal for one workload and critical for another. Alert on baseline changes, growth rate, and business impact, not only fixed thresholds. In Prometheus, functions like predict_linear() and deriv() can help catch queues, lag, or disk usage trending toward failure.

Conclusion

RabbitMQ, Kafka, and ActiveMQ each fail in their own way and surface that failure through different signals. Getting monitoring right means understanding those differences rather than applying the same checklist to all three.

The tooling is mature. The Prometheus pipeline covers all three through the exporter ecosystem. Platforms like CubeAPM add application-level correlation that turns broker metrics into something actionable during an incident rather than another dashboard to scroll through.

Start with the checklist in Section 10. Get the critical alerts firing first, then build toward unified observability across your full messaging stack.

Disclaimer: Monitoring recommendations and alert thresholds can vary by broker version, workload, deployment model, and traffic pattern. Treat the examples in this article as a starting point, and tune them against your own RabbitMQ, Kafka, or ActiveMQ environment before using them in production.

FAQs