Skip to main content
ComponentsEngine
Availability2022.1 or later

Prerequisites

Lock down ActiveMQ management access

Dead-Letter Queue Monitoring

Detect failed message deliveries

Recommended Alerts

Thresholds matched to workload

Troubleshooting

Resolve broker monitoring problems

​
Apache ActiveMQ Observability

​
Overview

GermainUX monitors the availability, health, capacity, and performance of Apache ActiveMQ brokers and destinations. Monitoring helps teams detect:
  • Broker unavailability
  • Growing message backlogs
  • Slow or inactive consumers
  • Failed message delivery
  • Dead-letter queue activity
  • Resource exhaustion
  • Connection problems
  • Broker errors and exceptions
GermainUX collects available ActiveMQ metrics through configured management interfaces and can correlate them with broker logs, JVM telemetry, host resources, and the applications that produce or consume messages.

​
Prerequisites

Before configuring ActiveMQ monitoring:
  • Deploy a GermainUX Engine with network access to the broker.
  • Enable the required ActiveMQ management interface, typically JMX.
  • Create a dedicated monitoring account with read-only permissions.
  • Confirm access to the broker logs if log monitoring is required.
  • Identify the brokers, queues, topics, and environments to monitor.
  • Confirm that clocks are synchronized across GermainUX, ActiveMQ, and connected systems.
Do not expose the ActiveMQ management interface to untrusted networks. Restrict access to the GermainUX Engine and other approved management hosts.

​
Broker Monitoring

GermainUX can monitor available broker measurements such as: The exact measurements depend on the ActiveMQ edition, version, configuration, and management data exposed to GermainUX.

​
Queue Monitoring

Queue monitoring helps identify destinations where messages are accumulating or failing to be processed. Common measurements include:
  • Current queue size
  • Enqueued message count and rate
  • Dequeued message count and rate
  • Dispatched messages
  • In-flight messages
  • Producer count
  • Consumer count
  • Expired messages
  • Pending messages
  • Average message processing or wait time, when available
  • Queue memory usage
A growing queue does not always indicate a problem. Compare queue depth with message throughput, consumer availability, expected processing schedules, and business volume. For example, a sustained increase in queue depth combined with a falling dequeue rate or no active consumers indicates a likely processing problem.

​
Topic Monitoring

For configured topics, GermainUX can monitor available measurements such as:
  • Producer and consumer counts
  • Enqueued and dequeued messages
  • Dispatch activity
  • In-flight messages
  • Expired messages
  • Durable subscribers
  • Inactive durable subscribers
  • Pending messages for durable subscribers
Topic and subscriber metrics depend on what the broker exposes through its management interface.

​
Dead-Letter Queue Monitoring

Monitor the ActiveMQ dead-letter queue and any custom dead-letter destinations for:
  • New dead-letter messages
  • Message-volume trends
  • Repeated delivery failures
  • Sudden increases after a release or configuration change
  • Destinations or applications associated with failures
A dead-letter message indicates that ActiveMQ could not complete normal message delivery. GermainUX detects and reports the available broker metric or log event; investigating message content requires appropriate access and must follow data-security requirements.

​
JVM and Host Monitoring

Because ActiveMQ runs on the JVM, broker performance should be analyzed together with Java and host resources. GermainUX can monitor configured measurements including:
  • JVM heap usage
  • Garbage-collection activity
  • Thread activity
  • JVM availability
  • Process CPU and memory
  • Host CPU and memory
  • Disk and filesystem utilization
  • Network availability and response time
  • ActiveMQ process and service state
High broker memory or store utilization can reduce throughput or prevent additional messages from being accepted. Alerts should be configured before the configured limits are reached.

​
Log Monitoring

The GermainUX Engine can monitor accessible ActiveMQ log files for configured patterns such as:
  • Startup and shutdown events
  • Connection failures
  • Authentication or authorization failures
  • Transport errors
  • Persistence-store errors
  • Out-of-memory conditions
  • Slow-consumer warnings
  • Message-expiration events
  • Failed or repeated delivery
  • Network-connector failures
  • Exceptions and warnings
Configure parsing and categorization rules for the log formats used by each ActiveMQ environment. Avoid collecting message bodies, credentials, tokens, or other sensitive content from logs.

​
Network and Integration Monitoring

Where the required telemetry is available, GermainUX can monitor:
  • Broker endpoint availability
  • Connection response time
  • Connection errors and timeouts
  • Network-connector status
  • Producer and consumer availability
  • Application or integration logs
  • APIs and services associated with message processing
End-to-end correlation requires shared identifiers, compatible timestamps, and telemetry from the producing and consuming applications. ActiveMQ metrics alone do not provide the complete processing history of every message.

​
Configure ActiveMQ Monitoring

1

Deploy or select a GermainUX Engine

2

Create the ActiveMQ host or management data source

3

Configure the broker hostname, management port, and credentials

4

Test the connection

5

Select the brokers, queues, topics, and metrics to monitor

6

Configure the collection frequency

7

Add broker-log and host monitoring where required

8

Configure KPIs, SLAs, alerts, and categorization

9

Save and enable the monitoring components

10

Verify that data appears in GermainUX

Use collection frequencies appropriate for the operational importance and expected activity of each destination. Monitoring every temporary or dynamically created destination may produce unnecessary data volume. Configure alerts for conditions such as:
  • Broker unavailable
  • ActiveMQ process or service stopped
  • Queue depth above its acceptable limit
  • Queue depth growing continuously
  • No active consumer on a critical queue
  • Dequeue rate below the expected level
  • Dead-letter messages detected
  • Expired-message volume increased
  • Memory, store, or temporary-store utilization is high
  • Connection count changed unexpectedly
  • Network connector unavailable
  • Broker errors or exceptions detected
  • Host disk space is low
Thresholds should reflect normal workload, destination purpose, processing schedule, and business impact.

​
Dashboards and Reports

ActiveMQ dashboards can include:
  • Broker availability and uptime
  • Message throughput
  • Queue depth
  • Top queues by backlog
  • Producer and consumer counts
  • Dead-letter and expired messages
  • Broker memory and store utilization
  • Connections
  • JVM and host resources
  • Errors and warnings
  • SLA violations
Scheduled reports can summarize current values, trends, changes from the previous period, recurring issues, and the destinations requiring attention.

​
Automation

When an ActiveMQ issue is detected, GermainUX can initiate approved actions through the Engine, such as:
  • Sending an alert
  • Creating or updating a ticket
  • Calling a webhook or HTTP endpoint
  • Executing an authorized diagnostic script
  • Collecting additional evidence
  • Restarting an approved service
  • Validating recovery
Automatic remediation must be explicitly configured and tested. Restarting a broker, moving messages, purging a destination, or modifying production messaging data can affect business transactions and should require appropriate authorization and safeguards.

​
Validation

After enabling monitoring:
1

Confirm that GermainUX can connect to the broker

2

Verify broker, queue, and topic metrics

3

Compare selected values with the ActiveMQ management console

4

Confirm that JVM and host metrics are associated with the correct broker

5

Generate a controlled test message

6

Verify enqueue and dequeue activity

7

Test an alert condition safely

8

Confirm that alerts reach the appropriate recipients

9

Verify that credentials and sensitive log content are protected

​
Troubleshooting

​
The broker cannot be monitored

Verify that:
  • The GermainUX Engine can reach the management endpoint.
  • JMX or the selected management interface is enabled.
  • The hostname and port are correct.
  • TLS and authentication settings match the broker configuration.
  • Firewall rules permit the connection.
  • The monitoring account has sufficient read permissions.

​
Destination metrics are missing

Confirm that:
  • The queue or topic exists and is active.
  • The destination is exposed through the management interface.
  • Monitoring filters include the destination.
  • Dynamic or temporary destinations have not disappeared.
  • The ActiveMQ version exposes the requested metric.

​
Queue alerts are too frequent

Review:
  • Normal traffic peaks
  • Batch-processing schedules
  • Minimum-duration requirements
  • Queue-growth rate
  • Consumer activity
  • Maintenance periods
  • Separate thresholds for queues with different workloads

​
Additional Resources

Engine Deployment

Read more

AI

Insights & Recommendations

Analytics

More Analytics Features

Automation

More Automation Features

Dashboards

Dashboards and reports overview

Reports

Automatic and scheduled reports

​
Get Help

Contact GermainUX Support

The GermainUX team helps you get up and running faster, empower your team, turn data into actionable insights, and optimize performance to deliver measurable business outcomes.

Can't find what you need?

Search all GermainUX docs with Ctrl + K, or use the feedback buttons at the bottom of this page to tell us what is missing.

The content of this document is proprietary to GERMAIN SOFTWARE.