> ## Documentation Index
> Fetch the complete documentation index at: https://docs.germainux.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ActiveMQ Observability

> GermainUX monitors the availability, health, capacity, and performance of Apache ActiveMQ brokers and destinations.

Components
[`Engine`](https://docs.germainux.com/main/germain-ux-engine)

Availability
2022.1 or later

> [card] [Prerequisites](#prerequisites)
>
> Lock down ActiveMQ management access

> [card] [Dead-Letter Queue Monitoring](#dead-letter-queue-monitoring)
>
> Detect failed message deliveries

> [card] [Recommended Alerts](#recommended-alerts)
>
> Thresholds matched to workload

> [card] [Troubleshooting](#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.

> [!WARNING]
>
> 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:

| Measurement | Description |
| - | - |
| Broker availability | Whether the broker management endpoint can be reached |
| Uptime | Time since the broker last started |
| Connections | Number of active client connections |
| Sessions | Active messaging sessions |
| Producers | Number of connected message producers |
| Consumers | Number of connected message consumers |
| Message throughput | Rate of messages entering and leaving the broker |
| Stored messages | Messages currently retained by the broker |
| Memory utilization | Broker memory usage relative to its configured limit |
| Store utilization | Persistent-message store usage |
| Temporary-store utilization | Storage used for temporary messages |
| Broker errors | Errors and exceptions found in accessible logs |

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

> [accordion] Show all 11
>
> * 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

> [accordion] Show all 9
>
> * 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

> [accordion] Show all 11
>
> * 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.

## Recommended Alerts

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

> [accordion] Show all 13
>
> * 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

> [accordion] Show all 11
>
> * 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

> [card] [Engine Deployment](https://docs.germainux.com/main/germain-ux-engine.md)
>
> Read more

> [card] [AI](https://docs.germainux.com/main/ai-driven-insights.md)
>
> Insights & Recommendations

> [card] [Analytics](https://docs.germainux.com/main/analytics.md)
>
> More Analytics Features

> [card] [Automation](https://docs.germainux.com/main/automation.md)
>
> More Automation Features

> [card] [Dashboards](https://docs.germainux.com/main/dashboard-and-report.md)
>
> Dashboards and reports overview

> [card] [Reports](https://docs.germainux.com/main/reporting-automatic.md)
>
> Automatic and scheduled reports

## Get Help

> [card] [Contact GermainUX Support](https://docs.germainux.com/main/support.md)
>
> 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.

> [card] 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.