ActiveMQ Artemis · How-to Intermediate

Monitor ActiveMQ Artemis queue depth and dead-letter growth with OpenTelemetry

Scrape ActiveMQ Artemis metrics with the OpenTelemetry Collector and stream them into Sluicio — so a backing-up queue or a filling dead-letter queue raises an alert.

SLSluicio team 9 min read Updated Jun 2026

On ActiveMQ Artemis, two numbers tell you an integration is in trouble: a queue depth that keeps climbing (consumers can’t keep up) and a dead-letter queue that’s filling (messages are failing and being parked). Artemis exposes both through its metrics system; this guide turns on a Prometheus endpoint, scrapes it with the OpenTelemetry Collector, and sends the result to Sluicio as OTLP — no application code involved.

1 · Expose Artemis metrics

Artemis has a pluggable metrics system. The community artemis-prometheus-metrics-plugin registers a Prometheus endpoint (it ships with recent Artemis distributions). Drop its jar in $ARTEMIS/lib if needed, then enable the plugin in broker.xml:

<core>
  <!-- … -->
  <metrics>
    <jvm-memory>true</jvm-memory>
    <plugin class-name="org.apache.activemq.artemis.core.server.metrics.plugins.ArtemisPrometheusMetricsPlugin"/>
  </metrics>
</core>

Restart the broker and confirm the endpoint responds (it’s served by the embedded web server, default port 8161):

curl -s http://localhost:8161/metrics | grep artemis_message_count

2 · Scrape with the OpenTelemetry Collector

Point the Collector’s prometheus receiver at the Artemis endpoint and export OTLP to Sluicio:

receivers:
  prometheus:
    config:
      scrape_configs:
        - job_name: artemis
          scrape_interval: 30s
          metrics_path: /metrics
          static_configs:
            - targets: ['localhost:8161']

exporters:
  otlphttp/sluicio:
    endpoint: https://your-instance-name.sluicio.com
    headers:
      authorization: Bearer ${env:SLUICIO_INGEST_KEY}

service:
  pipelines:
    metrics:
      receivers: [prometheus]
      exporters: [otlphttp/sluicio]

docker run --rm \
  -v "$(pwd)/otel-collector-config.yaml:/etc/otelcol-contrib/config.yaml" \
  -e SLUICIO_INGEST_KEY \
  otel/opentelemetry-collector-contrib:latest

Each queue and address arrives in Sluicio within a scrape interval, tagged with queue and address labels.

3 · Key metrics

Artemis exposes per-queue gauges through Micrometer. The ones that matter for backlog and failures:

Metric	What it tells you
`artemis_message_count`	Queue depth — messages currently on the queue.
`artemis_delivering_count`	Messages dispatched to consumers but not yet acknowledged.
`artemis_messages_added`	Total messages added — the source for an arrival rate.
`artemis_messages_acknowledged`	Total acknowledged — the source for a throughput rate.
`artemis_consumer_count`	Consumers attached to the queue.
`artemis_message_count{queue="DLQ"}`	Dead-letter growth — failed messages parked on the dead-letter queue.

4 · Read the signals

Backlog: artemis_message_count for a queue climbing while artemis_consumer_count holds steady — consumers are saturated.
Stalled queue: artemis_consumer_count == 0 while artemis_message_count > 0.
Failures piling up: artemis_message_count on your dead-letter address (default DLQ) trending up at all.

5 · Alert on queue depth and DLQ growth

Sustained backlog — artemis_message_count for a queue stays above your threshold for N minutes. As with any queue, weight the duration so a normal burst doesn’t page you.
Any DLQ growth — the dead-letter queue should be near-empty. Alert on a sustained increase in artemis_message_count{queue="DLQ"}, not just an absolute number: even a handful of new dead letters means messages are failing and being dropped from the flow.

Where to go next

Track RabbitMQ queue depth and consumer lag — the same pattern for RabbitMQ.
Monitor a file-drop integration (hot folder) — backlog monitoring for file-based flows.
Instrument a service — add traces to the consumer so a backed-up queue links to the slow code.