Let's say you have several hundred IoT devices publishing telemetry data to your MQTT broker and things have been working smoothly for months. One morning you notice half of the sensor readings have stopped arriving. Your monitoring dashboard becomes a black hole, your automation stops working, and you can't determine whether the problem is with the devices, the network, or the MQTT broker.
MQTT brokers are extremely useful and sometimes easy to take for granted. You set up your IoT infrastructure with a broker, connect your devices, and everything works as expected. The broker reliably handles all the publish-subscribe messaging between devices and backend systems. That is until something goes wrong and you realize you have no visibility into the state or performance of the message queue itself.
In this article, we'll look at what MQTT brokers are and why monitoring them matters. You'll also learn how to set up monitoring with PRTG Network Monitor and some real-world use cases from manufacturing, smart building systems, and distributed IoT deployments.
MQTT (Message Queue Telemetry Transport) is a lightweight communication protocol for limited bandwidth and unreliable connections. This IoT protocol uses a pub/sub model where MQTT clients connect to a central message broker and it handles message routing and delivery.
Think of the broker as a traffic cop for your IoT data. MQTT clients publish messages to MQTT topics (such as warehouse/temperature/zone1) and the message broker routes those messages to any subscribers. Since the broker acts as a scalable pub/sub message broker, one publisher device can publish once and hundreds of subscribers receive that message without the publisher knowing who the subscribers are.
The MQTT broker manages MQTT connections and client connections, authenticates and authorizes clients, handles topic subscriptions, and QoS (quality of service) levels. When you've got connected devices and IoT devices sending real-time data to production, you need proper monitoring to ensure it's reliable and optimized for performance.
MQTT brokers seem simple but they present unique operational challenges. Large-scale and scalable IoT deployments scale rapidly. You start with fifty sensors and within months have thousands of IoT devices with persistent TCP connections. Without tracking MQTT connections, message throughput, and queue depth, you won't see the performance cliff until after you've driven off it.
Message delivery reliability is important for real-time operations. The MQTT protocol has three quality of service (QoS) levels (0, 1, and 2) that provide different message delivery guarantees. You need monitoring to confirm that your broker actually honors these guarantees under heavy load or unstable network conditions.
Authentication and access control can be complex. Modern MQTT infrastructure uses TLS/SSL encryption and other authentication mechanisms, and without proper monitoring, you risk missing certificate expiration, authentication errors, or unauthorized access attempts. Real-time performance also matters because latency means your automation and decision-making systems act on stale data.
"How can I possibly keep on top of all this chaos?" I hear you cry! PRTG Network Monitor comes with specialized MQTT sensors—a complete solution that lets you monitor your MQTT broker from multiple vantage points without writing custom infrastructure or complex CLI tools. The MQTT sensors provide your dashboard with visibility into functionality and performance metrics across your MQTT infrastructure. Lets look at the native PRTG options:
The MQTT Round Trip sensor acts as both a publisher and subscriber by connecting to the MQTT broker and publishing an MQTT message through a pre-configured MQTT topic. The sensor times how long the entire round trip takes to give you real-time visibility into responsiveness and message flow. The sensor tracks round-trip time, subscriber connection time, and the MQTT connection status to help spot performance issues as they occur.
This is a form of active monitoring because it simulates real MQTT client behavior. Instead of just checking whether the broker's TCP port is accepting connections, you're verifying it can receive, route, and deliver messages successfully under current load conditions. This active testing approach is critical to ensuring scalable operations.
The MQTT Statistics sensor subscribes to MQTT topics you specify (including wildcards) and tracks the MQTT messages flowing through them. This is extremely valuable when you need to verify that specific IoT devices are publishing data or you want to check message rates on critical topics.
For example, you might configure MQTT Statistics sensors to monitor all topics that match factory/+/temperature. This would capture all messages being published for temperature sensors in every production zone. If the messages stop arriving on a specific topic, you'll immediately know whether it's a device issue or a broker problem.
The MQTT Subscribe Custom Sensor subscribes to a Message Queue Telemetry Transport (MQTT) topic and monitors up to ten numeric values from the received JSON data, letting you show downtime and custom numeric values.
All sensors support TLS/SSL encryption and MQTT authentication with username/password credentials. You can provide CA certificates for server authentication or client certificates for mutual TLS (client authentication), which means your monitoring matches your production security and access control requirements without compromises.
A manufacturing facility with sensors on production equipment might have dozens of machines publishing performance data like temperature, vibration, and operational status every few seconds. Backend systems subscribe to MQTT topics and trigger alerts when values cross safe operating thresholds for real-time operations.
You can use PRTG's MQTT Round Trip sensor to actively verify broker responsiveness and optimize message delivery. Deploy MQTT Statistics sensors to monitor specific topics that your critical production equipment publish to. When a sensor stops receiving messages from a specific topic (like factory/line3/temperature), you'll know immediately. This proactively prevents costly downtime in large-scale deployments.
Here's a true story - one customer in manufacturing actually discovered their broker was silently dropping messages when a network switch hit capacity during shift changes. Their equipment kept publishing but the backend never received critical alerts. MQTT monitoring revealed the pattern before an expensive equipment failure.
For distributed infrastructures with multiple remote locations, you need to know if those sites are successfully sending data to your central MQTT broker. Network issues, firewall changes, or ISP problems can silently break connectivity. This matters whether you're using cloud service platforms or on-premises MQTT deployments. Monitoring ensures you get reliable message delivery.
You can use sensors that subscribe to MQTT topics with wildcards (like sites/+/temperature) to track message flow across all remote sites. For cloud-based MQTT deployments such as AWS IoT Core, Azure IoT Hub, or other cloud service platforms, you can monitor MQTT connections alongside cloud service platform metrics for complete visibility. PRTG integrates with AWS and Azure monitoring to give you these unified dashboard views.
Smart building systems use the MQTT protocol to coordinate HVAC, lighting, access control, and energy management systems. When the message broker is having issues, that can mean comfort systems fail, security systems might not trigger properly, and energy waste goes undetected.
You can monitor MQTT topics that carry critical data like occupancy sensors, temperature control, and door access events. Set up alerts on your dashboard to fire when message rates drop below expected thresholds. If your occupancy sensors normally send messages every 30 seconds but suddenly stop publishing, that's either a sensor failure or a broker problem. Either way, you want to know immediately.
If you're not monitoring your MQTT infrastructure (or just looking at basic connectivity checks), here's a practical step-by-step guide.
Not every MQTT topic needs active monitoring, but you do want coverage on topics that drive automation or carry business-critical IoT data. You should also monitor topics that connect to expensive equipment. Create a list of these high-priority topics and the expected message rate for each. This lets you optimize your MQTT monitoring strategy and focus on critical use cases.
Configure your monitoring sensors with appropriate credentials and security settings to match your production deployment. If your MQTT broker requires TLS/SSL with client certificates, then set that up in PRTG's device-level MQTT credentials section. Don't skip this step and use insecure connections just to make monitoring easier. Proper authentication ensures your monitoring matches production security.
Configure alerts that make sense for your operations. A brief spike in round-trip time might not matter for low-priority telemetry, but it could be serious for real-time automation and message delivery. Set different thresholds based on topic criticality. Monitoring without a response plan is just expensive logging.
MQTT brokers don't operate in isolation. They run on servers (Linux, on-premises, or cloud service platforms like AWS and Azure), communicate over TCP networks, and depend on other backend infrastructure. PRTG's unified approach means you can see MQTT performance metrics alongside CPU usage, network bandwidth, disk I/O, and everything else that might affect your infrastructure. Correlating MQTT metrics with the underlying infrastructure when troubleshooting saves hours of guesswork.
Can I monitor multiple MQTT brokers with PRTG?
Absolutely. Each MQTT broker gets configured as a separate device, and you can deploy as many sensors as you need across as many brokers as you're running. This is particularly useful if you're operating brokers in different geographic regions, running separate instances for development and production, or using a distributed architecture for high availability. PRTG's multi-probe architecture even lets you monitor from different network locations to verify connectivity and optimize performance from various points.
How do I monitor open-source brokers like Mosquitto?
PRTG's MQTT sensors work with any standards-compliant broker, including open-source MQTT brokers like Mosquitto, commercial MQTT platforms, and cloud services like AWS IoT Core or Azure. The sensors act as standard MQTT clients, so as long as your broker speaks the MQTT protocol, PRTG can connect. Configure the broker's address as the device in PRTG, set up credentials with the appropriate TCP port (typically 1883 for non-TLS or 8883 for TLS/SSL), and add the sensors you need.
What happens if my broker uses a non-standard port?
No problem. PRTG lets you specify custom TCP ports in the MQTT credentials configuration. Just enter whatever port your broker listens on, and the sensors will connect there instead of the default ports. This functionality works whether you're using standard MQTT, MQTT over WebSockets, or custom configurations.
MQTT brokers are too critical for casual or limited monitoring. Whether you're running a small IoT pilot or managing thousands of devices in large-scale deployments, you need visibility into performance, message delivery, and connection health. Good monitoring lets you maintain reliable operations, prevent downtime, optimize performance, and ensure your IoT devices are talking to each other effectively.
PRTG's MQTT sensors provide that visibility without requiring custom infrastructure, GitHub plugins, or complex CLI tools. You get active testing of message flow, topic-specific statistics, and integration with network and server monitoring—all in one scalable platform with a unified dashboard.
If you're ready to stop flying blind with your MQTT infrastructure, download your free trial of PRTG Network Monitor. You get 100 sensors for 30 days with no strings attached which is more than enough to test both the MQTT sensors against your actual deployment and see how proper monitoring improves your operations.