ActiveMQ

Auto-Detection

Built-in Metrics

Apache ActiveMQ is a popular, open-source message broker written in Java that handles communication between different software systems.

Auto-Detection

Glouton discovers ActiveMQ instance by its process and command line. To gather metrics, Glouton queries the web console port (default: 8161) instead of the broker port (default: 61616). If the auto-detected parameters are incorrect, you can override them manually.

Linux

sudo tee /etc/glouton/conf.d/99-activemq.conf > /dev/null << 'EOF'
service:
  # For an ActiveMQ running outside a container
  - type: "activemq"
    address: "127.0.0.1"
    port: 8161
    username: "admin"
    password: "REPLACE_WITH_YOUR_PASSWORD"

  # For an ActiveMQ running in a Docker container
  - type: "activemq"
    instance: "CONTAINER_NAME"
    port: 8161
    username: "admin"
    password: "REPLACE_WITH_YOUR_PASSWORD"
EOF

Windows

Create or edit C:\ProgramData\glouton\conf.d\99-activemq.conf:

service:
  - type: "activemq"
    address: "127.0.0.1"
    port: 8161
    username: "admin"
    password: "REPLACE_WITH_YOUR_PASSWORD"

Glouton automatically detects configuration changes.

Requirements

• The web console must be deployed. The upstream ActiveMQ distribution and the official container image ship it; no Debian or Ubuntu activemq package does, so on those the broker is detected and checked but reports no metrics until the console is installed.
• The console always requires authentication. When no username or password is configured, Glouton falls back to the broker’s factory account (admin / admin).

For an ActiveMQ in a container, ACTIVEMQ_WEB_USER and ACTIVEMQ_WEB_PASSWORD are read from the container environment, so a containerized broker usually needs no configuration at all.

Built-in Metrics

Queue and topic metrics carry a name label holding the destination they describe, so there is one series per queue and per topic. ActiveMQ’s own advisory topics are excluded.

Metric	Description
service_status	Status of ActiveMQ
activemq_queues_consumer_count	Number of consumers on ActiveMQ queues
activemq_queues_dequeue_count	Number of ActiveMQ messages dequeued from queues, per second
activemq_queues_enqueue_count	Number of ActiveMQ messages enqueued on queues, per second
activemq_queues_size	Number of ActiveMQ messages waiting in queues
activemq_topics_consumer_count	Number of consumers on ActiveMQ topics
activemq_topics_dequeue_count	Number of ActiveMQ messages dequeued from topics, per second
activemq_topics_enqueue_count	Number of ActiveMQ messages enqueued on topics, per second

Metrics not Collected by Default

ActiveMQ also reports one series per subscription, carried by the client_id, destination_name and subscription_name labels. A broker with many consumers turns that into a lot of series for little benefit, so they are gathered but not sent unless you ask for them:

Metric	Description
activemq_subscribers_pending_queue_size	Number of ActiveMQ messages waiting to be dispatched to the subscriber
activemq_subscribers_dispatched_queue_size	Number of ActiveMQ messages dispatched to the subscriber and not yet acknowledged
activemq_subscribers_dispatched_counter	Total number of ActiveMQ messages dispatched to the subscriber since the broker started
activemq_subscribers_enqueue_counter	Total number of ActiveMQ messages enqueued for the subscriber since the broker started
activemq_subscribers_dequeue_counter	Total number of ActiveMQ messages acknowledged by the subscriber since the broker started

Unlike the queue and topic counters above, the three _counter metrics are sent as the broker’s running totals, not as per-second rates.

activemq_subscribers_pending_queue_size is the one worth watching: on a durable subscription it is the backlog piling up while the consumer is disconnected.

Add them with metric.allow_metrics; see Metrics Filtering.

metric:
  allow_metrics:
    - "activemq_subscribers_pending_queue_size"
    - "activemq_subscribers_dispatched_queue_size"
    - "activemq_subscribers_dispatched_counter"
    - "activemq_subscribers_enqueue_counter"
    - "activemq_subscribers_dequeue_counter"

Monitoring Troubleshooting

See Troubleshoot a Service Check or Missing Metrics for what applies to every service: finding the address and port Glouton really uses, what each check message means, and how to read the collection error — which does not appear in the agent logs at the default level.

The Service Check is not OK

The check only opens the web console’s TCP port so it fails when nothing listens there (Connection refused), when a firewall drops the packets (connection timed out after 10 seconds), or when the configured address cannot be parsed (Invalid TCP address). A green check proves the port is open, and nothing more: it says nothing about the credentials.

Metrics are Missing

Reproduce what Glouton does, from the machine where the agent runs. It reads three endpoints on every gather — queues, topics and subscribers — and stops at the first one that fails, so a single broken endpoint costs every ActiveMQ metric:

curl -su admin:admin 'http://127.0.0.1:8161/admin/xml/queues.jsp' | head
curl -su admin:admin 'http://127.0.0.1:8161/admin/xml/topics.jsp' | head
curl -su admin:admin 'http://127.0.0.1:8161/admin/xml/subscribers.jsp' | head

What you see	Cause	Fix
401 Unauthorized	The factory account no longer exists, and no credentials are configured	Set username and password
403 Forbidden	The account exists but belongs to no group allowed on the console	Give it the console’s group in conf/groups.properties
404 Not Found	The web console is not deployed	Install it, or use a distribution that ships it
a connection error	The console is bound to another address or port	Set address / port, or stats_url for the console’s base URL — Glouton appends /admin/xml/queues.jsp itself