How to Generate a Diagnostic Archive When HiveMQ Control Center UI Is Not Available
In rare cases, HiveMQ versions prior to 4.38 or 4.28.13-LTS may crash or become unresponsive when the Control Center (Admin UI) is accessed. The UI may appear stuck in a “loading” state.
Instructions
📌 Root Cause
The exact cause could not be determined from the logs, but preliminary analysis suggests:
A possible violation of minimal hardware requirements
A spike in CPU load when the Admin UI is accessed
⚠️ This is not a known HiveMQ bug, but similar symptoms may occur due to resource exhaustion or outdated versions.
✅ Recommended Resolution
1. Upgrade HiveMQ
Upgrade to the latest stable version (4.38) or the LTS release (4.28.13) as soon as possible.
New versions include numerous performance and stability improvements.
Download: HiveMQ Downloads
🧪 Optional: Troubleshooting Steps Before Upgrade
If you want to investigate further before upgrading, follow these safe diagnostic steps:
A. Generate Diagnostic Archive Without UI Access
You can generate a Diagnostic Archive without opening the HiveMQ Control Center.
Run the following command on the HiveMQ machine:
touch /opt/hivemq/data/diagnostic-trigger.txt
This will automatically trigger the diagnostic archive generation in the background.
B. Generate Diagnostic Archive Without UI Access
You can generate a Diagnostic Archive without opening the HiveMQ Control Center.
https://docs.hivemq.com/hivemq/latest/rest-api/specification/#operation/createDiagnosticArchive
Run the following command on the HiveMQ Broker REST API:
curl -X POST http://localhost:8888/api/v1/management/diagnostic-archives
This will automatically trigger the diagnostic archive generation in the background.
C. Enable Debug Logging (Temporary)
To capture more context around the crash:
Set environment variable:
HIVEMQ_LOG_LEVEL=DEBUG
Or modify
/opt/hivemq/conf/logback.xml
⚠️ Don't forget to revert back to INFO after debugging to reduce log volume.
C. Monitor Resource Usage
Check CPU, memory, and JVM metrics around the time of the crash using your preferred observability stack.
Example signs of resource pressure:
High CPU usage
Heap memory
I/O wait increase