La supervision d'un broker MQTT vous indique si les messages circulent avant que vos clients ne vous signalent qu'ils ne circulent plus. Ce guide couvre les métriques qui comptent vraiment (connexions, débits de messages, messages perdus, latence et nombre de retained messages), la manière de les transformer en alertes sans bruit et la construction d'une sonde simple de bout en bout. Vous verrez aussi comment surveiller un broker dans le portail ConnectMQ.
Pourquoi la supervision d'un broker est différente
La défaillance d'un serveur web fait généralement du bruit : les requêtes échouent et les taux d'erreur s'envolent. Les défaillances MQTT sont souvent silencieuses. Un abonné peut rester connecté mais ne plus rien recevoir, parce que son abonnement a été perdu après une reconnexion sans session persistante. Des appareils peuvent être connectés sans rien publier parce qu'un pilote de capteur est bloqué. La file d'un client hors ligne peut grossir en silence jusqu'à atteindre les limites.
Une bonne supervision combine donc trois points de vue :
- Les métriques côté broker : ce que voit le broker, comme les connexions, le débit et les pertes.
- Les métriques côté client : ce que voient les appareils et les applications, comme les échecs de connexion et le nombre de reconnexions.
- Les sondes de bout en bout : un client synthétique qui publie et reçoit, pour mesurer si le système fonctionne dans son ensemble.
Si vous découvrez ces composants, commencez par le rôle d'un broker MQTT.
Les métriques qui comptent pour la supervision d'un broker MQTT
| Métrique | Ce qu'elle vous apprend | Alerte typique |
|---|---|---|
| Clients connectés | Santé de la flotte, pannes, tempêtes de connexions | Chute ou pic soudain par rapport à la référence |
| Tentatives et échecs de connexion | Problèmes d'identifiants, attaques, limites | Taux d'échec supérieur à la normale |
| Messages reçus par seconde | Activité de publication | Chute proche de zéro pour une flotte habituellement active |
| Messages envoyés par seconde | Livraison aux abonnés | Écart par rapport à la diffusion attendue |
| Messages perdus ou rejetés | Files pleines, limites de taille ou de quota | Tout taux non nul persistant |
| Messages inflight et en file | Consommateurs lents ou hors ligne | Croissance continue |
| Latence de bout en bout | Délai perçu par l'utilisateur | Au-dessus de votre objectif pendant plusieurs minutes |
| Nombre de retained messages | Hygiène des topics, croissance du stockage | Croissance inattendue |
| Nombre d'abonnements | Fuites dans le code client | Croissance continue sans nouveaux clients |
| Utilisation des ressources (auto-hébergé) | CPU, mémoire, descripteurs de fichiers | Approche des limites |
Connexions
Le nombre de clients connectés est le pouls de votre flotte. Suivez-le comme une série temporelle et apprenez sa forme quotidienne. Une falaise signale une panne, un problème réseau ou un certificat expiré. Un motif en dents de scie, fait de chutes et de remontées, signifie généralement que des clients sont déconnectés à répétition, souvent à cause de client IDs en double ou d'un keepalive trop court sur des réseaux instables.
Débits de messages
Les débits reçus et envoyés montrent si les données circulent. Pour une flotte qui remonte ses mesures chaque minute, le débit reçu doit être à peu près prévisible. Comparez envoyés et reçus : le ratio reflète la diffusion (fan-out), et un changement brutal signifie que des abonnés ont disparu ou sont apparus.
Messages perdus et rejetés
Les brokers perdent ou rejettent des messages pour des raisons concrètes : payload trop volumineux, quota dépassé, file pleine pour un consommateur lent, ou messages QoS 0 destinés à un client qui ne suit pas. En MQTT 5, beaucoup de ces cas sont visibles par le client sous forme de reason codes, comme 0x97 (Quota exceeded). Journalisez les reason codes côté client : c'est souvent le diagnostic le plus rapide dont vous disposez.
Latence
La latence est ce que ressentent les utilisateurs. Mesurez-la de bout en bout : horodatez un message chez l'éditeur et comparez à son arrivée chez un abonné. Suivez des percentiles, pas seulement des moyennes, car une médiane saine peut masquer une longue traîne. La région compte aussi ; voir la latence d'un broker MQTT selon la région.
Retained messages et abonnements
Les retained messages et les abonnements doivent suivre votre conception des topics. Une croissance sans limite pointe généralement vers un bug, comme des noms de topics dynamiques contenant des horodatages, ou des clients qui se réabonnent à chaque reconnexion.
N'oubliez pas les métriques côté client
Le broker ne voit que ce qui l'atteint. Les appareils et les services backend doivent remonter leur propre santé : combien de tentatives de connexion ont échoué et pourquoi, à quelle fréquence ils se sont reconnectés, combien de mesures attendent dans la mémoire tampon hors ligne, et les reason codes renvoyés dans les CONNACK, PUBACK et DISCONNECT. Publiez un message de santé compact sur un topic de statut toutes les quelques minutes, en retained, pour que les tableaux de bord affichent toujours la dernière valeur. Lorsqu'un site devient muet, ces derniers rapports expliquent souvent pourquoi avant même que quelqu'un se déplace.
Brokers auto-hébergés : d'où viennent les métriques
Si vous exploitez votre propre broker, les métriques proviennent du broker lui-même. Mosquitto, par exemple, publie des statistiques sur des topics $SYS/ comme $SYS/broker/clients/connected et $SYS/broker/messages/received. Les brokers en cluster exposent généralement des API HTTP ou des endpoints de métriques à collecter. Vous les raccordez ensuite à votre système de supervision, construisez des tableaux de bord, définissez des alertes et ajoutez les métriques de l'hôte comme le CPU, la mémoire et les descripteurs de fichiers ouverts. La documentation de Mosquitto liste les topics $SYS disponibles.
Construire une sonde de latence de bout en bout
Quel que soit votre broker, une sonde synthétique est le contrôle le plus précieux. Elle se connecte comme un client normal, publie un message horodaté sur un topic privé, le reçoit en retour et enregistre le temps d'aller-retour. Cette sonde Python utilise paho-mqtt 2.x et fonctionne telle quelle avec le serveur MQTT public gratuit, réservé aux tests ; en production, passez aux identifiants de votre broker privé et au port 8883.
import json
import statistics
import time
import uuid
import paho.mqtt.client as mqtt
HOST, PORT = "broker.connectmq.com", 1883
PROBE_ID = uuid.uuid4().hex[:8]
TOPIC = f"connectmq/demo/{PROBE_ID}/probe"
INTERVAL = 5 # secondes entre deux sondes
ALERT_MS = 500 # seuil d'alerte pour le temps d'aller-retour
latencies = []
def on_connect(client, userdata, flags, reason_code, properties):
print("Probe connected:", reason_code)
client.subscribe(TOPIC, qos=1)
def on_disconnect(client, userdata, flags, reason_code, properties):
print("Probe disconnected:", reason_code)
def on_message(client, userdata, msg):
sent = json.loads(msg.payload)["t"]
rtt_ms = (time.time() - sent) * 1000
latencies.append(rtt_ms)
flag = " ALERT" if rtt_ms > ALERT_MS else ""
print(f"rtt={rtt_ms:.0f} ms{flag}")
if len(latencies) % 12 == 0:
recent = latencies[-12:]
print(f"last 12: median={statistics.median(recent):.0f} ms max={max(recent):.0f} ms")
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"probe-{PROBE_ID}")
# Production : client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD"); client.tls_set(); PORT = 8883
client.on_connect = on_connect
client.on_disconnect = on_disconnect
client.on_message = on_message
client.reconnect_delay_set(min_delay=1, max_delay=60)
client.connect(HOST, PORT, keepalive=30)
client.loop_start()
try:
while True:
if client.is_connected():
client.publish(TOPIC, json.dumps({"t": time.time()}), qos=1)
else:
print("ALERT: probe not connected")
time.sleep(INTERVAL)
except KeyboardInterrupt:
client.loop_stop()
client.disconnect()
Faites tourner la sonde depuis les réseaux qu'utilisent vos appareils, pas seulement depuis votre data center, et transmettez ses alertes à votre outil d'astreinte ou de messagerie.
Transformer les métriques en alertes utiles
La lassitude face aux alertes tue la supervision. Quelques règles empiriques :
- Alertez sur les symptômes, pas sur les causes. « La sonde échoue depuis trois minutes » appelle une action ; « CPU à 70 % » généralement non.
- Utilisez des références. Comparez le nombre de connexions à la même heure la semaine précédente plutôt qu'à un chiffre fixe.
- Exigez de la persistance. Ne déclenchez qu'après plusieurs minutes de condition, pour absorber les coupures brèves.
- Séparez avertissement et astreinte. Une croissance lente des messages en file justifie un ticket ; zéro message d'une flotte active justifie un appel d'astreinte.
- Surveillez les surveillants. Alertez si la sonde elle-même cesse de remonter des données.
La supervision sur ConnectMQ
Avec un broker MQTT managé, le fournisseur supervise l'infrastructure, mais vous avez toujours besoin de visibilité sur votre propre trafic. ConnectMQ vous offre plusieurs outils dans le portail :
- Un tableau de bord offrant une vue d'ensemble de votre broker.
- Un explorateur de topics en direct pour voir les messages arriver en temps réel et repérer les topics devenus silencieux.
- Un client MQTT dans le navigateur pour publier et s'abonner lors de vérifications rapides, sans rien installer.
- Une vue des appareils qui organise les équipements par niveaux ISA-95, utile pour les flottes industrielles.
- Des règles d'alerte de seuil et un journal des alertes, pour que les valeurs hors plage déclenchent des alertes consultables ensuite.
Pour l'état de connexion par appareil, le broker publie l'état de connexion sur $SYS/broker/connection/{clientId}/state. Un service backend peut s'abonner au topic d'état des clients importants, comme les passerelles, et réagir quand l'un d'eux passe hors ligne. Combiné aux messages Last Will de vos appareils et à la sonde ci-dessus, cela couvre à la fois la santé au niveau du broker et au niveau applicatif. En dehors du portail, l'extension VS Code de ConnectMQ et l'explorateur MQTT Desktop sont pratiques pour inspecter le trafic pendant le développement.
Démarrer avec ConnectMQ
Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, et observez vos premiers messages dans l'explorateur de topics en direct en quelques minutes. Associez-le ensuite à la sonde ci-dessus et à la checklist de mise en production MQTT avant la mise en service. Le guide du broker MQTT cloud couvre le reste du panorama de l'hébergement.
Questions fréquentes
Quelle est la métrique la plus importante d'un broker MQTT ?
Le nombre de clients connectés, combiné à une sonde de bout en bout. Ensemble, ils montrent si les appareils sont en ligne et si les messages circulent réellement.
Comment mesurer la latence MQTT ?
Publiez un message contenant un horodatage et calculez la différence lorsqu'un abonné le reçoit. Suivez les percentiles dans le temps et faites tourner des sondes depuis les réseaux qu'utilisent vos appareils.
Pourquoi mon nombre de connexions chute-t-il puis remonte-t-il en dents de scie ?
Les causes courantes sont des client IDs en double qui s'expulsent mutuellement, des intervalles de keepalive trop courts pour le réseau, ou un watchdog côté appareil qui redémarre les clients.
Ai-je encore besoin de supervision avec un broker MQTT managé ?
Oui. Le fournisseur surveille son infrastructure, mais vous seul savez ce que vos appareils sont censés envoyer : supervisez donc votre propre trafic et ajoutez une sonde synthétique.
