Zabbix 5.2 supports two important protocols used in the world of the Internet of Things — MQTT and Modbus. Now we can benefit from the newest Zabbix features and integrate Zabbix network monitoring in the world of IoT.
Contents
I. What is MQTT? (3:32:13)
II. MQTT and Zabbix integration (3:39:48)
1.MQTT setup (3:40:03)
2.Node-RED (3:42:12)
3.Splitting data (3:45:45)
4.Publishing data from Zabbix (3:52:23)
III. Questions & Answers (3:55:42)
What is MQTT?
MQTT — the Message Queuing Telemetry Transport was invented in 1999, and designed to be bandwidth-efficient and lightweight, thus battery efficient. Initially, it was developed to allow for monitoring oil pipelines.
It is a well-defined ISO standard — ISO/IEC 20922, and it is getting increasingly adopted due to its suitability for the Internet of Things (IoT), sensor networks, home automation, machine-to-machine (M2M), and mobile applications. MQTT usually uses TCP/IP as the transport protocol — over ports 1883, and can be encrypted using TLS transport mechanism with 8883 as the default port.
There is a variation of MQTT available — MQTT-SN (MQTT for Sensor Networks) used for non-TCP/IP networks, such as Zigbee (IEEE 80215.4 radio-based protocol) or other UDP / Bluetooth-based implementations.
There are 2 types of network entities available: ‘Message broker‘ and ‘Clients‘.
MQTT supports 3 Quality-of Service levels:
— 0: At most once – “Fire and forget” where you might or might not receive the message.
— 1: At least once – The message can be sent/delivered multiple times.
— 2: Exactly once – Safest and slowest service.
MQTT is based on a ‘publish’ / ‘subscribe-to-topic’ mechanism:
1. Publish/subscribe.
Publish/subscribe pattern
MQTT Message Broker consumes messages published by clients (on the left) using two-level ‘Topics‘ (such as, for instance, office temperature, office humidity, or indoor air quality). The clients on the rights side act as subscribers receiving any information published on a particular topic. Every time a message is published to the broker, the broker notifies all of the subscribers (Clients 3 and 4), and these clients get the sensor value.
2. Combined publishing/subscribing
Combined pub/sub
A client can be a subscriber and a publisher at the same time. So, in this example, Client 1 is publishing a brightness value and Client 3 has a subscription for that brightness value. Client 3 may decide that the brightness, for instance, of 1,500 might be too low, so it can publish a new message to the topic ‘office’ to let the light controller know that it should increase the brightness, while Client 2, for instance, the light controller with a subscription, may change the brightness level on receipt of the message.
3. Wildcards subs
+ = single-level, # = multi-level
Wildcards in MQTT are easy. So, you can have, for instance, ‘office + brightness’ topic, where the ‘+’ sign can be substituted by any topic name. If the ‘+’ sign substitutes just one level in our topic, then it is a single-level wildcard. While the pound sign works for a multi-level wildcard.
MQTT features:
- Clients can publish and subscribe to one or more topics.
- One client can publish and subscribe at the same time.
- Clients can subscribe using single/multi-level wildcards.
- Clients can choose between three different QoS levels.
MQTT advanced features:
- Messages can be retained by the broker for new subscribers. So, if a new client subscribes to a particular topic, then the publisher can mark its messages as ‘Retained‘ so that the new subscriber gets the last retained message.
- Clients can provide a “last will and testament” that will be published by the broker when the client “dies”.
MQTT and Zabbix integration
MQTT setup
Integrating Zabbix into the multiple-client mix
Integrated structure:
1. Four sensors:
-
- Server room.
- Training room.
- Sales room.
- Support room.
2. Four different topics:
-
- office
- bielefeld (home town)
- serverroom
- trainingroom
3. Mosquitto MQTT Message Broker, which is one of the well-known message brokers.
So, the sensors are publishing the data to the Mosquitto Message Broker, where any MQTT-enabled device or system can pick those values up. In our case, it’s the home automation system, which subscribes to the Message Broker and has access to all of the values published by the sensors.
Thanks to MQTT support in Zabbix 5.2, Zabbix can now subscribe to the Mosquitto Message Broker and immediately get access to all of the sensors publishing their values to the broker.
As we can have multiple subscribers, multiple clients can subscribe to one topic on the Message Broker. So the home automation system can subscribe to the same values published to the Message Broker, as well as Zabbix.
Node-RED
Sooner or later, you will need Node-RED, which is a flow-based programming tool allowing you to subscribe to the broker and to publish messages to the broker acting as the client, as well as to work with the data.
Data Processing in Node-RED
This setup might be useful, if, for instance, some Zabbix trigger fires and passes the information over to the MQTT to publish the outcome of the trigger to the Message Broker, which will be then picked up by the home automation system.
Zabbix publishes data to the broker
You can have two different Zabbix instances subscribing to the same Message Broker acting just as two different clients.
Multiple Zabbix servers sharing the same data
Node-RED:
-
- Construction kit for the Internet of Things and home automation.
- Acts as MQTT client able to publish and subscribe.
- Flow-based tool for visual programming based on Node.js.
- Graphical web editor.
- Supports input, processing, and output nodes.
- Extensible with plugins and custom function nodes.
Different types of nodes can be connected in the workspace. For instance, the nodes subscribing to a topic and transforming the data, or the nodes writing the data to a log file.
We can get the data from the sensors as the raw JSON string containing 20-30 metrics in a payload, and as a parsed JSON object in the Node-RED Debug node with easy-to-read metrics, such as, for instance, temperature, humidity, WiFi quality, indoor air quality, etc.
Multiple metrics in one message
Splitting data
We have different options for data splitting available:
- Split on MQTT level: use Node-RED to split metrics and then publish them in their own topics (it’s good to set up when other clients can handle only a single metric at a time).
Splitting data in Node-RED
- Split on Zabbix level: set up an MQTT item as a master item and use Zabbix JSON preprocessing with corresponding dependent items. Its more efficient because Zabbix would need only one subscription.
We can get the data with the brand-new mqtt.get item in Zabbix 5.2:
— Requires Agent 2.
— Requires active checks. As every time a client publishes a message to the topic, we need the broker to push that data to us, we need active checks, so mqtt.get must listen to the subscription and get notified when the new data comes in.
— Broker URL default is localhost.
— User name and password are optional.
— Uses Eclipse Paho Go client library.
One Zabbix agent in active mode sending data to multiple hosts
For our setup with four sensors: in Sales Room, Server Room, Support Room, and Training Room, we need four hosts in Zabbix. Traditionally, you need four different agents to handle them as each agent running as active needs to configure its own hostname. However, in our setup, we need just one agent installed and handling different hosts by subscribing to multiple topics.
This is possible because of the new feature running active agent checks from multiple hosts which is now available in Zabbix 5.2. All we need is:
— to set up hosts in Zabbix (as usual),
— to define our MQTT items (as usual),
— to set up just one agent with all of the hostnames the agent should be responsible for (the new feature),
— to set up the master item, which is our mqtt.get item,
— to define several dependent items and preprocessing for each of the dependent items, and
— to start preprocessing with JSONPath.
NOTE. Every time the master item gets an update, so do all of the dependent items in Zabbix.
Master item and dependent items
- Combine both methods: let other clients subscribe to a single metric using their specific topic, but publish all sensor data for Zabbix in one topic.
NOTE. Data received and displayed on the dashboard is based on the MQTT item, the payload, and the MQTT messages received from the Message Broker.
Sensor data dashboard
Publishing data from Zabbix
Now you want to publish the outcome of a Zabbix trigger, so it can be consumed by other MQTT-enabled devices. Any MQTT subscriber, like Node-RED, should receive the alert. To do that, you need:
- to define a new media type to send problems to the topic, that is, to pass the data over to the Message Broker:
- to use the command-line tool for Mosquitto — mosquitto_pub allowing us to publish the message.
#!/bin/sh mosquitto_pub -h yourbroker.io -m "$1" -t "zabbix/problems/$2"
- to make sure that the data is sent to the broker in the right format. In this case, we use JSON as transport and define a JSON problem template and a JSON problem recovery template.
In Zabbix, you’ll see the problem, the actions, and the media type firing using the subscription, and in the Debug node of Note-RED, you’ll see that the data is received from Zabbix.
Zabbix problems published via MQTT
This model with Node-RED can be used to create sophisticated setups. For instance, you can take the data from Zabbix, forward it by actions and media types, preprocess them in Node-RED, and transform the data in many different ways.
IoT devices and other subscribers can react to issues detected by Zabbix using Node-RED
NOTE. To try out the MQTT setup and new Zabbix features, you can use the Live broker available on IntelliTrend new GitHub account, getting data from Zabbix sensors every 10 minutes. You’ll also find templates, access data, address of the broker, etc. — everything you need to to get started.
Questions & Answers
Question. If the MQTT client gets overloaded due to high message frequency on subscribe topics, how will that affect Zabbix?
Answer. Here the broker might be overloaded or the Zabbix agent might not be able to follow up. If for the problem with the broker, the quality of service levels is defined in the MQTT protocol, more specifically — QoS level 2, which guarantees delivery. So if QoS2 is used as a QoS level, the messages won’t get lost but would be resent in case of failure.
Question. What else would you expect from the IoT side of Zabbix? What kind of protocols or things would get added?
Answer. There’s always room for improvement. You can use third-party tools, custom scripts, or any tools to enhance Zabbix. I’m sure that using user script parameters was an excellent design decision. But the official support of MQTT is a quantum leap for Zabbix because it opens the door to most IoT infrastructures, as MQTT is the most important IoT protocol so far.
For instance, one of our customers is monitoring the infrastructure of electricity generators, production systems, etc. They use their own monitoring platform provided by vendors. The request was to integrate alerts or some metrics into Zabbix. The customer’s monitoring platform used MQTT protocol. So, all we had to do was to make their monitoring platform use external scripts and MQTT support.
