--- title: "ActiveMQ Log Analysis & Diagnostics: The Expert Guide" date: 2026-07-14 author: "TheFrameGuy" featured_image: "https://www.meshiq.com/wp-content/uploads/blog_activeMQ-log-analysis_071426.jpg" categories: - name: "Apache ActiveMQ®" url: "/sort-by/active-mq.md" - name: "Data Streaming" url: "/sort-by/data-streaming.md" - name: "Messaging" url: "/sort-by/messaging.md" - name: "Middleware" url: "/sort-by/middleware.md" - name: "Middleware Optimization" url: "/sort-by/middleware-optimization.md" - name: "Monitoring" url: "/sort-by/monitoring.md" - name: "MQ" url: "/sort-by/mq.md" - name: "SaaS" url: "/sort-by/saas.md" tags: - name: "devops" url: "/sort-by/tag/devops.md" - name: "monitoring" url: "/sort-by/tag/monitoring.md" - name: "Observability" url: "/sort-by/tag/observability.md" --- # ActiveMQ Log Analysis & Diagnostics: The Expert Guide This guide builds that map. We cover ActiveMQ log analysis and diagnostics end-to-end: the log anatomy (how to read any log entry), the 10 critical log signatures for the most common operational events, production log4j2 configuration for Apache ActiveMQ® and Apache Artemis™, audit logging for compliance environments, GC log correlation, and log aggregation integration. ## The ActiveMQ Log Format: Anatomy of a Log Entry ### Apache ActiveMQ® Log Format Apache ActiveMQ® produces pipe-separated log entries: TIMESTAMP | LEVEL | MESSAGE | LOGGER\_CLASS | THREAD\_NAME 2026-04-04 02:13:47,215 | WARN | Usage(default:store:queue://orders:store) percentUsage=99%… Stopping producer (ID:app-1:1:1:1) | org.apache.activemq.broker.region.BaseDestination | ActiveMQ Broker **Field****Example****What It Tells You**Timestamp2026-04-04 02:13:47,215Correlate with application events, GC pausesLevelWARNSeverity: TRACE < DEBUG < INFO < WARN < ERROR < FATALMessageStopping producer…The event description — the primary diagnostic contentLogger classorg.apache.activemq.broker.region.BaseDestinationWhich broker component generated the entryThread nameActiveMQ BrokerThe broker thread — identifies context (IO thread, checkpoint worker, etc.)### Apache Artemis™ Log Format Artemis uses space-separated fields and AMQ message codes: TIMESTAMP LEVEL \[THREAD\] LOGGER AMQ\_CODE: MESSAGE 2026-04-04 02:15:30,441 WARN \[org.apache.activemq.artemis.core.server\] AMQ222199: Thread dump: The AMQ message codes (AMQ2XXXXX) are numeric identifiers for specific broker events that can be used as search terms in aggregation systems regardless of message text changes across versions. ### Log Files Location Reference **Product****Primary Log****Audit Log****Config File**Apache ActiveMQ® 5.17.0+data/activemq.logdata/audit.logconf/log4j2.propertiesApache ActiveMQ® 5.16.xdata/activemq.logdata/audit.logconf/log4j.properties (reload4j)Apache Artemis™log/artemis.loglog/audit.logetc/log4j2.properties## Production Log4j2 Configuration The default log4j2 configuration that ships with ActiveMQ is serviceable for development but needs adjustment for production: rolling file size management, appropriate retention, and structured output for log aggregation. ### **Apache ActiveMQ®: conf/log4j2.properties** \# conf/log4j2.properties — Production configuration for Apache ActiveMQ(r) 5.17.0+ \# Hot-reload: check for config changes every 30 seconds (no broker restart needed) monitorInterval = 30 \# Root logger: INFO level, writing to rolling file + console rootLogger.level = INFO rootLogger.appenderRef.console.ref = console rootLogger.appenderRef.activemq.ref = activemq \# ── Component-level logger overrides ────────────────────────────────────────── \# Transport: useful to raise to DEBUG when diagnosing connection issues logger.transport.name = org.apache.activemq.transport logger.transport.level = INFO \# KahaDB: raise to DEBUG to trace journal operations during corruption investigation logger.kahadb.name = org.apache.activemq.store.kahadb logger.kahadb.level = INFO \# Network of Brokers: raise to DEBUG when diagnosing NoB connectivity logger.network.name = org.apache.activemq.network logger.network.level = INFO \# Security: INFO shows authentication events; DEBUG shows all JAAS operations logger.security.name = org.apache.activemq.security logger.security.level = INFO \# ── Console appender ────────────────────────────────────────────────────────── appender.console.type = Console appender.console.name = console appender.console.layout.type = PatternLayout appender.console.layout.pattern = %d %-5level \[%t\] %c{1}:%L %msg%n \# ── Rolling file appender: 10 × 50MB = 500MB max log retention ─────────────── appender.activemq.type = RollingFile appender.activemq.name = activemq appender.activemq.fileName = ${sys:activemq.base}/data/activemq.log appender.activemq.filePattern = ${sys:activemq.base}/data/activemq.log.%i appender.activemq.layout.type = PatternLayout appender.activemq.layout.pattern = %d | %-5level | %msg | %logger | %t%n appender.activemq.policies.type = Policies appender.activemq.policies.size.type = SizeBasedTriggeringPolicy appender.activemq.policies.size.size = 50MB appender.activemq.strategy.type = DefaultRolloverStrategy appender.activemq.strategy.max = 10 \# ── Audit log: Apache ActiveMQ(r) audit logging via system property ───────────────────── \# Enable via: ACTIVEMQ\_OPTS=”… -Dorg.apache.activemq.audit=true” \# Audit events write to data/audit.log ### Apache Artemis™: etc/log4j2.properties \# etc/log4j2.properties — Production configuration for ActiveMQ Artemis monitorInterval = 30 rootLogger = INFO, console, artemis \# ── Artemis component loggers ───────────────────────────────────────────────── logger.artemis\_server.name = org.apache.activemq.artemis.core.server logger.artemis\_server.level = INFO logger.journal.name = org.apache.activemq.artemis.journal logger.journal.level = INFO logger.security.name = org.apache.activemq.artemis.core.security logger.security.level = INFO \# ── Audit loggers: OFF by default; enable individually for compliance ───────── \# audit.base: JMX operations (queue creation, deletion, purge) logger.audit\_base.name = org.apache.activemq.audit.base logger.audit\_base.level = OFF logger.audit\_base.appenderRef.audit\_log\_file.ref = audit\_log\_file logger.audit\_base.additivity = false \# audit.resource: authentication events, queue changes via console or JMX logger.audit\_resource.name = org.apache.activemq.audit.resource logger.audit\_resource.level = OFF logger.audit\_resource.appenderRef.audit\_log\_file.ref = audit\_log\_file logger.audit\_resource.additivity = false \# audit.message: produce/consume/browse operations on each message logger.audit\_message.name = org.apache.activemq.audit.message logger.audit\_message.level = OFF logger.audit\_message.appenderRef.audit\_log\_file.ref = audit\_log\_file logger.audit\_message.additivity = false \# ── Console appender ────────────────────────────────────────────────────────── appender.console.type = Console appender.console.name = console appender.console.layout.type = PatternLayout appender.console.layout.pattern = %d %-5level \[%t\] %c{1}:%L %msg%n \# ── Rolling broker log ──────────────────────────────────────────────────────── appender.artemis.type = RollingFile appender.artemis.name = artemis appender.artemis.fileName = ${sys:artemis.instance}/log/artemis.log appender.artemis.filePattern = ${sys:artemis.instance}/log/artemis.log.%i appender.artemis.layout.type = PatternLayout appender.artemis.layout.pattern = %d %-5level \[%c\] %msg%n appender.artemis.policies.type = Policies appender.artemis.policies.size.type = SizeBasedTriggeringPolicy appender.artemis.policies.size.size = 50MB appender.artemis.strategy.type = DefaultRolloverStrategy appender.artemis.strategy.max = 10 \# ── Separate audit log file ─────────────────────────────────────────────────── appender.audit\_log\_file.type = RollingFile appender.audit\_log\_file.name = audit\_log\_file appender.audit\_log\_file.fileName = ${sys:artemis.instance}/log/audit.log appender.audit\_log\_file.filePattern = ${sys:artemis.instance}/log/audit.log.%i appender.audit\_log\_file.layout.type = PatternLayout appender.audit\_log\_file.layout.pattern = %d %-5level \[%t\] %msg%n appender.audit\_log\_file.policies.type = Policies appender.audit\_log\_file.policies.size.type = SizeBasedTriggeringPolicy appender.audit\_log\_file.policies.size.size = 20MB appender.audit\_log\_file.strategy.type = DefaultRolloverStrategy appender.audit\_log\_file.strategy.max = 10**Hot-reload**: the monitorInterval=30 setting causes Log4j2 to re-read the configuration file every 30 seconds. To raise a logger to DEBUG for a targeted troubleshooting session, edit the \*.level line, save the file, and wait 30 seconds; no broker restart is required. This is the correct procedure for production troubleshooting with minimal disruption. ## 10 Critical Log Signatures: The Diagnostic Reference These are the log entries that matter most for operational diagnosis. Recognizing them immediately without searching through documentation is what separates fast incident response from slow. ### Signature 1: Producer Flow Control (PFC) Activated INFO | Usage(default:store:queue://orders.process:store) percentUsage=99%, usage=107374182400, limit=107374182400: Persistent store is Full, 100% of 107374182400. Stopping producer (ID:app-server-1:1:1:1) to prevent flooding queue://orders.process. (blocking for: 1800s)**What it means**: A resource limit (store/temp/memory) has been reached. The producer is blocked. The blocking for time tells you how long this has been active. If this is >5 minutes, it is an active incident. **Action**: Read the resource type from Usage(default:TYPE:…). Match to the PFC decision matrix in our **[Producer Flow Control Troubleshooting](https://www.meshiq.com/blog/activemq-producer-flow-control-troubleshooting/)** guide. If blocking for is growing, the resource is not clearing. ### Signature 2: Broker Startup Complete INFO | Apache ActiveMQ 5.18.3 (localhost, ID:app-server-1-1234567890-0:1) started INFO | For help or more information, please see: http://activemq.apache.org INFO | ActiveMQ WebConsole available at http://0.0.0.0:8161/ INFO | Connector openwire started INFO | Connector amqp started **What it means**: Normal startup complete. Note the broker ID (ID:app-server-1-…). This changes on each restart and is used in PFC log entries to identify which producer is blocked. Confirm all expected connectors appear in the log, a missing Connector mqtt started line means the MQTT transport failed to bind its port. ### Signature 3: KahaDB Journal Recovery on Startup INFO | KahaDB is version 6 INFO | Recovering from the journal @0:0 INFO | Recovery replayed 45231 operations from the journal in 127.3 seconds. **What it means**: Normal behavior after an unclean shutdown (power loss, OOM kill, SIGKILL). The broker is replaying journal records to rebuild the in-memory state. The time shown is the RTO for this startup event. If this takes longer than expected for your data volume, investigate the KahaDB index cache size (indexCacheSize) and consider whether journal files have grown unexpectedly. **Concerning variant**: INFO | Detected missing/corrupt journal files. Dropped 3 messages from the index in 0.003 seconds.This means some journal records were skipped due to corruption. See our **[Backup and Disaster Recovery](https://www.meshiq.com/blog/activemq-backup-disaster-recovery/)** post for the recovery procedure. ### Signature 4: OutOfMemoryError – Heap Space ERROR | java.lang.OutOfMemoryError: Java heap space | org.apache.activemq.broker.BrokerService | ActiveMQ Broker **What it means**: The JVM heap is exhausted. If the broker configured -XX:+HeapDumpOnOutOfMemoryError, a heap dump file will have been written to the configured path. The broker will likely crash or become unresponsive. **Before the crash** look for this warning sequence that often precedes the OOM: WARN | Memory usage exceeded threshold: 90% | org.apache.activemq.usage.MemoryUsage | ActiveMQ Broker This WARN is the early-warning signal. Configure a log-based alert on this pattern, and you can act before the OOM occurs. We covered the three OOM types and their fixes in our **[JVM Memory & GC Tuning](https://www.meshiq.com/blog/activemq-jvm-memory-gc-tuning/)** guide. ### Signature 5: Transport Connection Drop / Client Disconnect WARN | Transport Connection to: tcp://10.0.1.42:51234 failed: java.net.SocketException: Connection reset | org.apache.activemq.transport.tcp.TcpTransport | ActiveMQ Transport: tcp://…**What it means**: A client connection dropped unexpectedly (not a clean close()). This is normal for transient network events. **Concerning pattern**: the same client IP appearing repeatedly in rapid succession indicates a client that is crashing and reconnecting in a loop, or a network path with instability. **Distinct from clean disconnect**: INFO | Connector openwire Stopped A clean connector stop is an INFO, not WARN. A transport failure is always WARN or ERROR. ### Signature 6: Inactive Connection Cleanup INFO | Inactive for longer than 600000 ms – removing … tcp://10.0.1.55:49102@61616 **What it means**: A TCP connection has been idle for 10 minutes (600,000ms is the default inactivity timeout) and has been cleaned up by the broker. This is normal behavior, the broker automatically removes dead connections to reclaim resources. Seeing this frequently for the same client IP indicates a client that is not keeping its connection alive and may need to configure connection factory heartbeats. ### Signature 7: KahaDB Corruption Detected INFO | Corrupt journal records found in ‘db-326.log’ between offsets: 19460423-21031378 | org.apache.activemq.store.kahadb.MessageDatabase | main ERROR | Failed to start ActiveMQ JMS Message Broker. Reason: java.io.EOFException | org.apache.activemq.broker.BrokerService | main **What it means**: The KahaDB journal contains corrupt records. The broker may or may not start depending on configuration. The sequence of INFO | Corrupt journal records found followed by ERROR | Failed to start means checkForCorruptJournalFiles=true is working as intended, it detected and stopped rather than silently discarding data. ### Signature 8: GC Overhead Limit / OOM GC Overhead ERROR | java.io.IOException: Unexpected error occurred: java.lang.OutOfMemoryError: GC overhead limit exceeded **What it means**: The JVM is spending >98% of time on garbage collection but recovering <2% of heap. The heap is permanently saturated. This is distinct from Java heap space OOM, the GC overhead limit indicates the heap is full AND the GC cannot reclaim it, typically because everything in the heap is live (slow consumer message accumulation, memory leak). This is the type that benefits most from enabling checkForCorruptJournalFiles=true + PFC configuration rather than simply increasing the heap. ### Signature 9: Network of Brokers / Bridge Connection Loss WARN | Failed to create network connection between: this#0 and: tcp://broker2:61616 Error: could not connect. Reason: java.net.ConnectException: Connection refused | org.apache.activemq.network.NetworkConnector | ActiveMQ Network Connector: … **What it means**: A network connector to a remote broker has failed. The NoB bridge is down. Depending on your topology, this may affect message routing across brokers. The WARN will repeat at the reconnect interval, frequent repetition is expected while the remote broker is unavailable. ### Signature 10: Apache Artemis™ Critical Analyzer: Thread Unresponsive WARN \[org.apache.activemq.artemis.core.server\] AMQ224081: The component org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl@… is not responsive ERROR \[org.apache.activemq.artemis.core.server\] AMQ224079: The process for the virtual machine will be killed, as component … is not responsive **What it means**: Apache Artemis™’s built-in Critical Analyzer has detected that a broker component has stopped responding. The broker will generate a thread dump (AMQ222199) and then either kill the JVM (KILL policy) or shut down (SHUTDOWN policy) depending on critical-analyzer-policy in broker.xml. This is a self-protection mechanism against deadlocks and I/O freezes. The thread dump in the log is the primary diagnostic artifact, look for threads in BLOCKED state holding locks needed by other threads. ## Critical Log Signatures Reference Table **Signature****Level****Key String****Meaning****Urgency**PFC ActivatedINFOStopping producerResource limit hitHigh if blocking for > 5minBroker StartedINFOApache ActiveMQ … startedNormal startupInformationalJournal RecoveryINFORecovering from the journalNormal post-crashWatch recovery timeOOM — Heap SpaceERROROutOfMemoryError: Java heap spaceHeap exhaustedCriticalConnection DropWARNTransport Connection to: … failedClient disconnectedMedium (high if repeated)Inactive CleanupINFOInactive for longer than 600000 msNormal cleanupInformationalKahaDB CorruptionINFO+ERRORCorrupt journal records foundJournal corruptedCriticalOOM — GC OverheadERRORGC overhead limit exceededHeap permanently fullCriticalNoB Bridge DownWARNFailed to create network connectionCross-broker path lostHighCritical AnalyzerWARN+ERRORAMQ224081 / AMQ224079Apache Artemis™ component frozenCritical## Audit Logging: Compliance and Security Investigation Audit logging records management operations – queue creation/deletion, purges, authentication events, and message operations to a separate audit.log file. It is disabled by default and must be explicitly enabled. ### Apache ActiveMQ® Audit Logging Enable via system property in bin/env: \# bin/env — Classic audit logging activation ACTIVEMQ\_OPTS=”$ACTIVEMQ\_OPTS \\ -Dorg.apache.activemq.audit=all” \# Values: true (entry events only) | exit (completion events) | all (both) \# Logs to: ACTIVEMQ\_HOME/data/audit.log Apache ActiveMQ(r) audit log entries: 2026-04-04 14:22:07,225 | INFO | admin requested /admin/createDestination.action \[JMSDestination=’orders’ JMSDestinationType=’queue’\] from 192.168.1.10 | qtp12205619-39 2026-04-04 14:22:57,553 | INFO | admin called org.apache.activemq.broker.jmx.QueueView.purge\[\] | RMI TCP Connection(8)-192.168.1.10Each entry captures: username (or “anonymous”), the operation (HTTP endpoint or JMX method name), parameters, and the client IP. This provides a complete management audit trail for compliance purposes. ### Apache Artemis™ Audit Logging Enable in etc/log4j2.properties by changing logger levels from OFF to INFO: \# Enable audit logging for all three audit loggers logger.audit\_base.level = INFO # JMX operations: queue create/delete/purge logger.audit\_resource.level = INFO # Auth: login success/failure, queue changes via console logger.audit\_message.level = INFO # Message ops: produce, consume, browse **Apache Artemis™ audit log entries:** 2026-04-04 14:30:00,841 INFO \[org.apache.activemq.audit.resource\] User admin@192.168.1.10 is creating a queue on target: orders.main notification: CREATE\_QUEUE 2026-04-04 14:31:15,223 INFO \[org.apache.activemq.audit.message\] User svc-consumer@10.0.1.25 is consuming a message from orders.main with messageID=… We covered the security implications of audit logging, including which audit events are relevant for HIPAA, PCI-DSS, and SOC 2 compliance requirements in our [**Security Hardening Guide**](https://www.meshiq.com/blog/activemq-security-hardening-guide/) post. The key point: enabling audit.message on high-throughput queues generates extremely high log volume. For compliance, selectively enable it only on the queues and addresses that contain regulated data. ## ****Are Your ActiveMQ Logs Telling You Everything They Should?**** Most ActiveMQ deployments run with a default logging configuration – rolling files too small, no audit log, no GC log correlation, no aggregation. meshIQ’s team reviews logging and observability configurations and can identify gaps that are leaving critical operational signals uncaptured. [******Request a Logging Review******](https://www.meshiq.com/apache-activemq/enterprise-support/) ## GC Log Correlation: Connecting JVM Events to Broker Behavior The broker log and the GC log are two independent observability streams that must be analyzed together to diagnose latency incidents. A message delivery gap in the broker log may be caused by either a broker-level resource event (PFC, slow consumer) or a JVM-level GC stop-the-world pause. Without GC log correlation, these two root causes are indistinguishable from the broker log alone. **Scenario**: a consumer application reports 500ms message delivery gaps at irregular intervals. The broker log shows no PFC events during those times. The GC log shows: 2026-04-04 02:13:47.110 \[5.892s\]\[info\]\[gc\] GC(12) Pause Full (G1 Compaction Pause) 2026-04-04 02:13:47.621 \[5.892s\]\[info\]\[gc\] GC(12) Pause Full (G1 Compaction Pause) 511ms 511ms at exactly the timestamp of the consumer-reported gap. The root cause was a G1GC full GC event, not a broker resource issue. The fix is GC tuning, not broker configuration. **How to correlate**: \# Find all GC pause events in GC log with duration > 100ms grep “Pause Full” /opt/activemq/data/gc.log | awk -F’ms’ ‘$1>100’ \# Find all PFC events in broker log grep “Stopping producer” /opt/activemq/data/activemq.log \# Cross-correlate timestamps (within 1-second window) \# If PFC events and GC events share timestamps → GC caused the resource pressure \# If only GC events match → GC pause is the root cause The -Xlog:gc\*:file=… configuration recommended there produces GC logs whose timestamp format is compatible with the broker log for direct correlation. ## Log Aggregation: From Reactive Forensics to Proactive Alerting Searching log files on individual broker hosts is sufficient for forensics but insufficient for proactive operations. Log aggregation, shipping ActiveMQ logs to a centralized platform (ELK Stack, Loki/Grafana, Splunk, Sumo Logic), transforms logs from reactive incident artifacts into real-time alert sources. ### Key Log-Based Alert Patterns \# Prometheus (via Loki log scraping) — alert on PFC events \# Fires as soon as any PFC event appears count\_over\_time({job=”activemq”} |= “Stopping producer” \[5m\]) > 0 \# Alert on OOM warning (leading indicator before OOM crash) count\_over\_time({job=”activemq”} |= “Memory usage exceeded threshold” \[5m\]) > 0 \# Alert on KahaDB corruption detection count\_over\_time({job=”activemq”} |= “Corrupt journal records found” \[5m\]) > 0 \# Alert on repeated connection drops from same IP (possible client crash loop) count\_over\_time( {job=”activemq”} |= “Transport Connection to:” |= “failed:” \[5m\] ) > 10 \# Alert on Artemis critical analyzer activation count\_over\_time({job=”activemq”} |= “AMQ224081” \[5m\]) > 0### Configuring Structured Logging for Aggregation For log aggregation tools, JSON-structured output significantly improves parsing and query performance over the default pipe-separated format. Log4j2 provides a JsonLayout that produces machine-parseable output: \# JSON layout for log aggregation (replaces PatternLayout in appender config) appender.activemq.layout.type = JsonLayout appender.activemq.layout.complete = false appender.activemq.layout.compact = true appender.activemq.layout.locationInfo = true \# Produces: {“instant”:{“epochSecond”:1714795200},”level”:”WARN”,”message”:”…”}This output is directly parseable by Filebeat, Logstash, Fluentd, and Promtail (for Loki) without custom pattern configuration. We covered the full Prometheus + Grafana monitoring stack integration, including metric-based alerting that complements log-based alerting in our [**Monitoring & Alerting Setup**](https://www.meshiq.com/blog/activemq-monitoring-alerting-setup/) post. ## Targeted DEBUG Logging: The Right Way to Deep-Dive When a specific component is behaving unexpectedly, and INFO logs don’t show enough detail, enabling DEBUG for that logger namespace gives deep visibility without drowning the entire log in noise. \# Targeted DEBUG examples — enable only the relevant namespace \# Diagnosing connection drops or transport errors: logger.transport\_debug.name = org.apache.activemq.transport logger.transport\_debug.level = DEBUG \# Tracing KahaDB journal operations during recovery investigation: logger.kahadb\_debug.name = org.apache.activemq.store.kahadb logger.kahadb\_debug.level = DEBUG \# Tracing NoB bridge connection and subscription behavior: logger.network\_debug.name = org.apache.activemq.network logger.network\_debug.level = DEBUG \# Artemis journal I/O tracing: logger.artemis\_journal\_debug.name = org.apache.activemq.artemis.journal logger.artemis\_journal\_debug.level = DEBUG \# SECURITY WARNING: never enable TRACE on security loggers in shared environments \# logger.security\_trace.name = org.apache.activemq.security \# logger.security\_trace.level = TRACE # Would log credentials in some configurationsWith monitorInterval=30 in the production config, these logger-level additions take effect within 30 seconds of saving the file. Revert the level to INFO as soon as the troubleshooting session is complete. **The DEBUG volume warning**: DEBUG logging on org.apache.activemq.transport on a high-connection broker (hundreds of clients) will generate multiple log entries per message per connection. On a broker handling 10,000 messages/second, DEBUG at the transport level can produce gigabytes of logs per hour. Always scope DEBUG logging to the narrowest namespace that will reveal the issue. ## Log Diagnostics Workflow: The 5-Step Process When a broker incident is reported, apply this workflow before assuming you know the root cause: **Step 1: Establish the incident timeline** \# What changed in the last 30 minutes before the incident was reported? grep “2026-04-04 0\[1-2\]:” /opt/activemq/data/activemq.log | tail -100 **Step 2: Scan for ERROR and WARN level events in the window** grep -E “ERROR|WARN” /opt/activemq/data/activemq.log | grep “2026-04-04 02:” **Step 3: Check for PFC events** grep “Stopping producer” /opt/activemq/data/activemq.log | tail -20 \# Note the ‘blocking for’ duration in the most recent entry **Step 4: Check GC log for stop-the-world pauses in the same window** grep “Pause Full\\|Pause Young” /opt/activemq/data/gc.log | grep “2026-04-04 02:” **Step 5: Cross-reference timestamps** If Step 3 shows PFC starting at 02:13:47, and Step 4 shows a 511ms GC pause at 02:13:47, the GC pause likely triggered the memory pressure that caused PFC. Fix the GC issue first. ## ******Unified Log + Metric Visibility for Your ActiveMQ Fleet****** meshIQ Console correlates broker metrics and log events in a single dashboard, surfacing PFC events, OOM warnings, connection drop rates, and KahaDB recovery sequences alongside queue depth, consumer count, and memory utilization charts. No more switching between log files and metric dashboards during an incident. [********See It in Action********](https://www.meshiq.com/request-a-demo/) ## The Log Is the Source of Truth Every significant ActiveMQ operational event has a log signature. The broker log is not noise, it is a structured record of everything the broker has done and everything it encountered. Knowing the 10 critical signatures, having a production log4j2 configuration that captures rolling history, enabling audit logging for compliance, correlating GC logs with broker events, and shipping logs to an aggregation platform where alerts fire on PFC and OOM patterns – these together give you an operational posture where incidents are discovered from logs before users report them. **Get your ActiveMQ log and observability configuration reviewed by our team → [Request a Review](https://www.meshiq.com/apache-activemq/enterprise-support/)** ## **Frequently Asked Questions** **Q1: Where are ActiveMQ log files located?** Apache ActiveMQ®: data/activemq.log (broker log) and data/audit.log (if enabled), configured in conf/log4j2.properties (5.17.0+). Apache Artemis™: log/artemis.log and log/audit.log, configured in etc/log4j2.properties. **Q2: How do I enable DEBUG logging in ActiveMQ?** Edit log4j2.properties and add/change the logger level for the target namespace. With monitorInterval=30, the change takes effect within 30 seconds without a restart. Revert to INFO after troubleshooting, DEBUG at transport or store level on a high-throughput broker produces enormous log volume. **Q3: What does ‘Stopping producer to prevent flooding’ mean in ActiveMQ logs?** Producer Flow Control (PFC) has been activated, a resource limit was reached. The log identifies the resource type (store/temp/memory), the destination, the producer ID, and the block duration. See our **[Producer Flow Control Troubleshooting](https://www.meshiq.com/blog/activemq-producer-flow-control-troubleshooting/)** guide for the complete diagnosis procedure. **Q4: How do I enable audit logging in ActiveMQ?** Apache ActiveMQ®: set -Dorg.apache.activemq.audit=all in ACTIVEMQ\_OPTS. Apache Artemis™: change the audit logger levels in etc/log4j2.properties from OFF to INFO. Three independent Artemis audit loggers cover JMX operations, authentication events, and message operations. **Q5: What log level should I use in production ActiveMQ?** INFO is the correct production level. It captures all meaningful operational events without the volume of DEBUG. Configure rolling files with at least 500MB of retention (10 × 50MB files) to preserve enough history for post-incident forensics.