HiveMQ Health API: MQTT Platform Monitoring Made Easy
The HiveMQ Health API now offers comprehensive insights into the health of the HiveMQ Platform. It not only provides Readiness and Liveness REST API resources for every node in a HiveMQ cluster but also includes detailed status and health information for each installed HiveMQ extension. This enhancement allows for thorough monitoring of the HiveMQ MQTT Broker and its extensions. Site Reliability Engineers (SREs) can leverage this data to proactively oversee platform health, swiftly identify and address issues, and maintain maximum uptime.
What is the Health API, and What Does It Do?
HiveMQ's platform serves as a core component of our customers' IoT deployments. Our customers rely on the HiveMQ Platform to enable various use cases in industries, such as predictive maintenance in smart manufacturing, critical infrastructure surveillance in energy, or high-value asset tracking in transportation and logistics.
Since the HiveMQ Platform is at the core of complex IoT deployments that support these use cases, our customers need to be able to monitor its health. They need access to operational information about the HiveMQ Broker’s components and installed platform extensions to ensure everything continues to run smoothly.
We released the Health API in the 4.14 platform release. The API provides liveness and readiness checks for every node in your HiveMQ cluster. These checks help you identify the precise status of each HiveMQ node and determine the cluster's overall state quickly and accurately.
The liveness check tells you whether your broker is running and responsive.
The readiness check tells you whether the MQTT component of your HiveMQ Broker is ready to serve traffic.
This information appears in a well-structured format that helps you quickly identify any issues in the broker or its components, ensuring the smooth operation of your HiveMQ deployment.
What Makes the Health API Worthwhile for SREs?
HiveMQ clusters are deployed in diverse environments, ranging from on-premises data centers to managed cloud services like AWS, Azure, or GCP. Maintaining outstanding cluster availability is critical to ensuring smooth operations of IoT deployments.
Together, the (liveness and readiness) health checks provide a way to verify the health of an MQTT cluster and ensure that traffic is routed only to components that are ready and able to handle it.
The health checks return HTTP status codes that show the current state of each node in your cluster.
Status code 200 indicates that the node can accept MQTT traffic.
Status code 503 shows that the node is currently unavailable.
Each health check response also provides additional information in a human-readable JSON format for deeper insights:
As illustrated in the image above, the health API provides information about the status of the HiveMQ Broker and HiveMQ MQTT Listeners — MQTT listeners specify the IP address and port on which HiveMQ accepts incoming connections from MQTT clients.
Site Reliability Engineers (SREs) can use this API to monitor the HiveMQ Platform’s health. They can use this in-depth information to quickly detect any issues and build self-healing systems to ensure the highest possible availability.
What is New in the Health API?
In the 4.28 platform release, the Health API functionality was expanded to include a subcomponents section that offers crucial status and health details for every enterprise extension installed in your HiveMQ cluster.
The Status section provides critical information about the current status of any installed extension, including enterprise or custom extensions. Here, you can view whether an extension is "UP," "DEGRADED," or "DOWN," along with its start time, license information, and configuration summary.
Let’s use the Enterprise Extension for Kafka as an example.
Monitoring the Health of the Enterprise Extension for Kafka
The following JSON block shows the status of the HiveMQ Enterprise Extension for Kafka.
The top section provides general information about the extension, such as the following:
| Information field | Sample information |
|---|---|
| The author of this extension | HiveMQ |
| Extension status: enabled/disabled | Enabled |
| The name of the extension | HiveMQ Enterprise Extension for Kafka |
| The priority of the extension is the order in which the extension is loaded. The highest-priority extensions are loaded first. | 1 |
| The starting time of the extension (expressed as time since epoch) | 1714053790016 |
| The version of the HiveMQ Platform | 4.28 |
The internals subcomponent provides more details about the extension, including the License, Entry point, and services, while the application subcomponent summarizes the extension’s configuration. Each component of the Health API can be retrieved via a URL.
Conclusion
The HiveMQ team will continue to enhance and provide more comprehensive status information on the broker and its extensions. As a result, the internal structure of the JSON node may change in the future to accommodate new components, services, and features being introduced.
We strongly suggest treating this block as dynamic and building integrations with this in mind.
Find out more about the HiveMQ Health API in our documentation.
Nasir Qureshi
Nasir Qureshi is a Senior Product Marketing Manager at HiveMQ. With a passion for working on disruptive technology products, Nasir has helped SaaS companies in their hyper-growth journey for over 3 years now. He holds an MBA from California State University with a major in Technology and Data Management. His interests include IoT devices, networking, data security, and privacy.
