How to Generate a Diagnostic Archive When HiveMQ Control Center UI Is Not Available

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

 Related articles