tutorial

Monitoring Apache ActiveMQ with Vigilmon: Broker Health, Queue Depth, DLQ, and JVM Heap

How to monitor Apache ActiveMQ Classic with Vigilmon — broker process health, queue depth alerts, dead letter queue accumulation, KahaDB persistence, JVM heap, and Web Console uptime.

Apache ActiveMQ Classic is one of the most widely deployed open source message brokers in enterprise Java — the backbone for asynchronous JMS messaging, point-to-point queuing, and publish-subscribe messaging across thousands of production deployments. When the ActiveMQ broker crashes, every JMS application in your stack loses the ability to send or receive messages. When queue depth climbs because consumers fall behind, messages pile up and application latency spirals. When the Dead Letter Queue fills with failed messages, data is silently lost. Vigilmon gives you external visibility into ActiveMQ's health: broker availability, Web Console uptime, and TCP transport port connectivity — the signals that tell you the broker is alive before your applications notice it isn't.

What You'll Set Up

  • Broker process health check via the ActiveMQ Web Console HTTP endpoint
  • TCP monitor on the OpenWire transport port to detect connection-level failures
  • Web Console uptime monitoring for operator visibility
  • SSL certificate monitoring for TLS-secured broker deployments
  • An alerting configuration mapped to ActiveMQ's key failure modes

Prerequisites

  • Apache ActiveMQ Classic (5.x) running on a server or container
  • Web Console enabled (default: http://your-broker:8161/admin)
  • OpenWire transport port accessible (default: 61616)
  • A free account at vigilmon.online

Step 1: Understand ActiveMQ's Externally Observable Ports

ActiveMQ exposes several ports. From a monitoring perspective, the critical ones are:

| Port | Protocol | Role | |---|---|---| | 61616 | OpenWire TCP | Primary JMS client transport (Java clients) | | 61613 | STOMP | STOMP protocol clients | | 61614 | STOMP over SSL | Secure STOMP | | 61617 | OpenWire SSL | Secure JMS clients | | 8161 | HTTP | Web Console and REST API | | 1883 | MQTT | IoT/MQTT clients | | 5672 | AMQP | AMQP clients |

External monitoring focuses on the Web Console (8161) and the OpenWire port (61616) — these confirm broker process health and client connectivity.

Step 2: Monitor the Web Console HTTP Endpoint

The ActiveMQ Web Console is served by the embedded Jetty server. When the broker is alive, the console responds with an HTML page containing queue and topic statistics. Use it as your primary broker health signal:

curl -u admin:admin http://your-broker:8161/admin/
# Returns HTML: "ActiveMQ Web Console"
  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: http://your-broker:8161/admin/ (use https:// if TLS is enabled).
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: ActiveMQ (present in the Web Console page title).
  7. HTTP Auth: Add Basic Auth credentials (admin / admin by default — change to your configured credentials).
  8. Label: ActiveMQ Web Console.
  9. Click Save.

This monitor catches broker JVM crashes, embedded Jetty failures, and out-of-memory conditions that kill the broker process.

Alert sensitivity: Set to trigger after 1 consecutive failure. A Web Console outage means the broker process is down — all JMS messaging has stopped.

Step 3: Monitor the OpenWire Transport Port via TCP Check

ActiveMQ's OpenWire port (61616) is the connection point for Java JMS clients. A TCP check confirms the port is accepting connections at the network level — independently of the Web Console:

# Test OpenWire port connectivity
nc -zv your-broker 61616
# Connected: port is open and accepting connections
  1. Add Monitor → TCP.
  2. Host: your-broker.example.com.
  3. Port: 61616.
  4. Check interval: 60 seconds.
  5. Label: ActiveMQ OpenWire transport.
  6. Click Save.

Why TCP in addition to HTTP? The Web Console and the OpenWire transport are served by different subsystems. In rare failure modes (e.g., embedded Jetty crashes but the broker transport is still running, or vice versa), the two checks catch different failure surfaces. More importantly, a firewall rule or load balancer misconfiguration might block port 61616 while leaving 8161 accessible — the TCP check catches that immediately.

Step 4: Monitor the REST API for Queue Depth (Optional — ActiveMQ 5.8+)

ActiveMQ 5.8+ exposes a REST management API that returns queue and topic statistics in JSON. If your broker is reachable and your monitoring infrastructure can reach the management API, use it for a richer health signal:

# Check all queues via the REST API
curl -u admin:admin \
  http://your-broker:8161/api/jolokia/read/org.apache.activemq:type=Broker,brokerName=localhost,destinationType=Queue,destinationName=YourQueue/QueueSize
# Returns JSON with "QueueSize" value

For a lightweight external check, create an HTTP monitor against the API's broker info endpoint:

  1. Add Monitor → HTTP.
  2. URL: http://your-broker:8161/api/jolokia/read/org.apache.activemq:type=Broker,brokerName=localhost/TotalEnqueueCount.
  3. Expected status: 200.
  4. Keyword: "status":200.
  5. Label: ActiveMQ Jolokia API.
  6. Click Save.

This monitor confirms the broker's management layer (Jolokia) is functional — a prerequisite for any tooling that reads queue depths and consumer counts.

Step 5: Monitor the STOMP Port (If Used)

If your applications use the STOMP protocol (Node.js, Ruby, Python, .NET clients), add a TCP monitor on the STOMP port:

  1. Add Monitor → TCP.
  2. Host: your-broker.example.com.
  3. Port: 61613.
  4. Check interval: 60 seconds.
  5. Label: ActiveMQ STOMP transport.
  6. Click Save.

Add a separate TCP monitor for AMQP (port 5672) and MQTT (port 1883) if those protocols are in use by your applications.

Step 6: Monitor SSL Certificates

If your ActiveMQ broker uses TLS for the Web Console or for the OpenWire SSL transport, set up certificate expiry monitoring:

openssl s_client -connect your-broker:8161 2>/dev/null | openssl x509 -noout -dates
  1. Add Monitor → SSL Certificate.
  2. Domain: your-broker.example.com.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

SSL certificate expiry on an ActiveMQ broker causes all TLS-connected JMS clients to fail immediately on connection — Java apps will throw SSLHandshakeException and be unable to send or receive any messages until the certificate is renewed.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Incident meaning | Action | |---|---|---|---| | Web Console HTTP | Non-200 or ActiveMQ missing | Broker JVM dead or Web Console crashed | Check broker process; inspect GC logs for OOM; restart ActiveMQ | | OpenWire TCP (61616) | Connection refused | Transport port down; JMS clients disconnected | Check firewall rules; verify broker is running; inspect broker logs | | Jolokia REST API | Non-200 or keyword missing | Management API degraded | Check broker logs; Jolokia plugin may be disabled | | STOMP TCP (61613) | Connection refused | STOMP clients disconnected | Verify STOMP transport is configured and enabled | | SSL Certificate | < 30 days to expiry | Certificate expiring | Renew certificate; test TLS connectivity after renewal |

Alert after: 1 consecutive failure for the Web Console and OpenWire monitors. 2 consecutive failures for STOMP and API monitors.

Common ActiveMQ Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Broker JVM out-of-memory (heap exhausted) | Web Console and TCP monitors fire; all clients disconnect | | KahaDB store full (message persistence limit reached) | Broker may still respond but reject new messages; Web Console fires if broker halts | | Dead Letter Queue accumulation | Not directly catchable externally — use Jolokia API monitor + internal alerting | | Consumer count drops to zero | Not directly catchable externally — use Jolokia API for DLQ and queue depth signals | | Network of brokers link failure | Broker stays up; routing fails silently — use internal ActiveMQ network connector metrics | | OpenWire port blocked by firewall | TCP monitor fires immediately; Web Console may still load on 8161 | | Embedded Jetty crash (Web Console down but broker alive) | Web Console monitor fires; TCP monitor stays green | | ActiveMQ upgrade rollback required | Web Console monitor fires during failed restart; TCP monitor fires if port doesn't come back | | SSL certificate expires | SSL monitor alerts at 30-day threshold; TLS clients fail with handshake errors | | DNS misconfiguration | All monitors fire simultaneously |

Queue Depth and Consumer Health Monitoring

Vigilmon monitors broker availability — the external signals that tell you ActiveMQ is running and accepting connections. Queue depth, consumer count, and Dead Letter Queue accumulation require internal metric collection:

  • Jolokia + Prometheus: Use the ActiveMQ Jolokia plugin with a Prometheus JMX exporter to scrape QueueSize, ConsumerCount, DequeueCount, and EnqueueCount per destination.
  • ActiveMQ metrics plugin: ActiveMQ 5.14+ ships with a Prometheus metrics plugin (activemq-metrics-plugin) that exposes /metrics in Prometheus format at http://your-broker:8161/metrics.
  • Alert thresholds: Alert when QueueSize > 10000 (consumer lag), ConsumerCount == 0 for a queue (orphaned queue), or DLQ MessageCount > 0 (message processing failures).

Vigilmon catches infrastructure-level failures (broker down, port unreachable, certificate expired). Queue-level health requires JMX or Prometheus-based internal monitoring.

ActiveMQ is the synchronous-to-asynchronous boundary for your entire Java messaging stack — when it goes down, applications queue up failed sends, consumers go idle, and transactional workflows stall. Vigilmon gives you the external health signal that tells you the broker is unreachable before your applications start logging connection errors: Web Console availability, OpenWire port connectivity, and SSL certificate health, so you can restore messaging before the backlog becomes a problem.

Start monitoring ActiveMQ in under 5 minutes — register free at vigilmon.online.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles