Avant qu'un broker MQTT ne serve de vrais appareils, déroulez cette checklist de test de broker MQTT : 25 vérifications concrètes, chacune avec une commande et le résultat attendu. Elle couvre la connectivité, TLS, l'authentification, les ACL, la sémantique des messages, la résilience et la capacité, c'est-à-dire les domaines où les incidents de production commencent réellement.
Tous les exemples utilisent les clients en ligne de commande de Mosquitto (mosquitto_pub, mosquitto_sub) et broker.connectmq.com. Remplacez l'hôte, les ports et les identifiants par ceux de votre broker. Sauf mention contraire, les clients parlent MQTT 3.1.1 ; ajoutez -V mqttv5 pour tester le comportement de MQTT 5.
export HOST=broker.connectmq.com
export T=testmqtt/checklist-$RANDOM # préfixe de topic unique pour cette exécution
export AUTH="-u $MQTT_USER -P $MQTT_PASS"
export TLS="-p 8883 --capath /etc/ssl/certs"Connectivité (vérifications 1–5)
1. Le DNS résout vers l'adresse attendue. dig +short $HOST renvoie les IP attendues depuis chaque réseau utilisé par vos clients (bureau, VPC cloud, APN cellulaire).
2. Chaque port de listener est joignable. Attendez succeeded (ou open) pour chaque port que vous comptez exposer, et un échec pour les autres :
for p in 1883 8883 8083 8084; do nc -zv -w 3 $HOST $p; done3. Un client reçoit un CONNACK. mosquitto_pub -h $HOST -t $T/ping -m hi -d affiche Client … received CONNACK (0). Toute autre réponse, ou un blocage, indique un problème de pare-feu, de proxy ou de listener.
4. L'endpoint WebSocket accepte l'upgrade. Les navigateurs ont besoin du port 8084 avec le chemin /mqtt. Le handshake doit répondre HTTP/1.1 101 Switching Protocols :
curl -si --http1.1 -m 5 https://$HOST:8084/mqtt \
-H "Connection: Upgrade" -H "Upgrade: websocket" \
-H "Sec-WebSocket-Version: 13" -H "Sec-WebSocket-Protocol: mqtt" \
-H "Sec-WebSocket-Key: $(openssl rand -base64 16)" | head -1Connectez-vous ensuite depuis le client MQTT en ligne pour confirmer qu'un vrai navigateur fonctionne aussi.
5. Le temps de connexion respecte le budget. time mosquitto_pub -h $HOST $TLS $AUTH -t $T/ping -m hi en TLS depuis la région de vos appareils. Fixez un budget (par exemple 1 à 2 secondes en cellulaire) et considérez la vérification comme échouée au-delà.
TLS et authentification (vérifications 6–11)
6. La chaîne de certificats et le nom d'hôte se vérifient. Attendez Verify return code: 0 (ok) et une date d'expiration lointaine de plusieurs mois :
openssl s_client -connect $HOST:8883 -servername $HOST -verify_return_error </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -enddateUn échec ici est ce que les appareils signaleront plus tard sous la forme certificate verify failed. Tester une connexion TLS MQTT couvre chaque variante.
7. Le texte clair est désactivé là où il doit l'être. Si les clients de production doivent utiliser TLS, le port 1883 de votre broker de production doit refuser les connexions (la vérification 2 doit échouer pour 1883).
8. Les clients anonymes sont refusés. Sans identifiants, attendez Connection error: Connection Refused: not authorised.
mosquitto_pub -h $HOST $TLS -t $T/anon -m x9. Les mauvais mots de passe sont refusés. Avec un mot de passe erroné, attendez Connection Refused: bad user name or password. (MQTT 5 : reason code 0x86). Consultez tout autre code avec l'outil des reason codes MQTT.
mosquitto_pub -h $HOST $TLS -u "$MQTT_USER" -P wrong-password -t $T/auth -m x10. Les ACL bloquent les topics étrangers. Connectez-vous en tant qu'utilisateur d'un appareil et publiez hors de son espace de noms. En MQTT 3.1.1, le broker supprime silencieusement le message : vérifiez donc avec un abonné privilégié que rien n'arrive. En MQTT 5 avec QoS 1, le PUBACK transporte le refus ; la sortie de débogage affiche RC:135 (0x87 Not authorized) :
mosquitto_pub -h $HOST $TLS $AUTH -V mqttv5 -q 1 -d -t other-tenant/secret -m x11. Les utilisateurs des appareils ne peuvent pas s'abonner à #. mosquitto_sub -h $HOST $TLS $AUTH -t '#' -C 1 -W 5 doit afficher All subscription requests were denied. Voir tester les permissions ACL MQTT pour un test complet de la matrice d'ACL.
Sémantique des messages (vérifications 12–18)
12. L'aller-retour publish/subscribe fonctionne. Abonnez-vous, publiez un jeton unique et recevez-le avant un timeout. Le script de smoke test d'une minute fait exactement cela, avec un code de sortie de réussite ou d'échec.
13. La QoS 1 est acquittée. mosquitto_pub -h $HOST -q 1 -d -t $T/qos -m x affiche received PUBACK. Avec -q 2, attendez PUBREC et PUBCOMP.
14. Les messages retenus sont stockés et effacés.
mosquitto_pub -h $HOST -t $T/retained -m on -r -q 1
mosquitto_sub -h $HOST -t $T/retained -C 1 -W 5 -v # affiche la valeur retenue
mosquitto_pub -h $HOST -t $T/retained -r -n # un payload retenu vide l'efface
mosquitto_sub -h $HOST -t $T/retained -C 1 -W 5 -v # timeout : plus rien de retenu15. Le Last Will est publié lors d'une déconnexion non propre.
mosquitto_sub -h $HOST -t $T/status -v &
mosquitto_sub -h $HOST -i lwt-check -k 5 -t $T/none \
--will-topic $T/status --will-payload offline &
sleep 2; kill -9 $! # crash simuléLe premier abonné affiche …/status offline. Un DISCONNECT propre ne doit pas le déclencher.
16. Les sessions persistantes mettent en file les messages hors ligne. Connectez-vous avec un client ID fixe et -c (clean session désactivé), arrêtez le client, publiez en QoS 1, puis reconnectez-vous avec la même commande : le message en attente arrive.
mosquitto_sub -h $HOST -i queue-check -c -q 1 -t $T/queue -W 3 # crée la session
mosquitto_pub -h $HOST -q 1 -t $T/queue -m while-offline
mosquitto_sub -h $HOST -i queue-check -c -q 1 -t $T/queue -C 1 -W 517. Les client ID en double se comportent comme prévu. Lancez deux clients avec le même -i ; le broker déconnecte le premier. Assurez-vous que chaque appareil génère un ID unique (le générateur de client ID aide), sinon vous verrez des boucles de reconnexion sans fin.
18. La taille maximale des messages est connue. Publiez un payload juste au-dessus de votre plus gros message réel et vérifiez le comportement du broker. Tester les gros payloads MQTT fournit un script de balayage des tailles.
Résilience (vérifications 19–22)
19. Les clients se reconnectent après un redémarrage du broker. En staging, redémarrez le broker (docker restart mosquitto ou systemctl restart mosquitto) et vérifiez que chaque type de client se reconnecte, se réabonne et reprend ses publications sans intervention manuelle.
20. Les connexions mortes sont détectées. Supprimez silencieusement le trafic vers le broker (sudo iptables -A OUTPUT -p tcp --dport 8883 -j DROP) et vérifiez que le client s'en aperçoit en environ 1,5 × son intervalle de keep-alive, puis retirez la règle. Le chaos testing MQTT montre comment automatiser cela avec tc netem et Toxiproxy.
21. Les reconnexions utilisent un backoff avec jitter. Après un redémarrage, les tentatives de connexion doivent s'étaler sur plusieurs secondes au lieu d'arriver en un seul pic. Consultez les logs du client ou le graphe du taux de connexions du broker.
22. Le failover fonctionne, si vous exploitez un cluster. Arrêtez un nœud et vérifiez que les clients basculent vers un autre, que les sessions survivent comme prévu et qu'aucun état retenu n'est perdu.
Capacité et exploitation (vérifications 23–25)
23. Le broker tient 2 × le pic attendu. Lancez un test de charge avec votre taille de payload, votre QoS et votre structure de topics réelles (voir test de charge d'un broker MQTT) et notez la latence p99 et le taux d'erreurs.
24. Les métriques sont visibles. Les clients connectés, les débits de messages et les messages supprimés apparaissent sur un dashboard. Sur Mosquitto (si autorisé) : mosquitto_sub -h $HOST $AUTH -t '$SYS/broker/clients/connected' -C 1 -v.
25. Les alertes se déclenchent vraiment. Provoquez-en une volontairement : arrêtez un client de test censé être toujours en ligne, ou pointez une vérification sur un certificat proche de l'expiration, et confirmez que l'alerte parvient à un humain.
Transformer la checklist en script
| Vérifications | Temps manuel | Comment automatiser |
|---|---|---|
| 1–6, 8–9, 12–16 | Minutes | Script Bash avec mosquitto_pub/mosquitto_sub, un code de sortie par vérification |
| 10–11, 17–18 | Minutes | Le même script avec des utilisateurs de test dédiés |
| 19–22 | Heures | Job de staging avec redémarrages et pannes réseau scriptés |
| 23–25 | Demi-journée | Test de charge planifié et règles de monitoring |
Commencez par scripter les vérifications rapides et exécutez-les en CI et après chaque modification du broker ; gardez les plus lentes dans la checklist de release.
Lancer les vérifications 3, 12 et 14 dans le navigateur
Un broker qui passe ces 25 vérifications a prouvé ce qui compte le premier jour : les clients le joignent de façon sécurisée, seuls les bons clients entrent, les messages se comportent comme prévu et les pannes se réparent d'elles-mêmes. Gardez les commandes dans votre dépôt et relancez-les chaque fois que le broker, sa configuration ou ses certificats changent.
Questions fréquentes
Combien de temps faut-il pour dérouler une checklist de test de broker MQTT ?
Les vérifications de connectivité, de sécurité et de messagerie prennent moins d'une heure à la main et quelques secondes une fois scriptées. Celles de résilience et de charge nécessitent un environnement de staging et prennent généralement une demi-journée la première fois.
Quelles vérifications MQTT comptent le plus avant la mise en production ?
TLS avec un certificat valide, le refus des connexions anonymes et des mauvais mots de passe, des ACL qui bloquent les topics étrangers, un Last Will fonctionnel et la reconnexion des clients après un redémarrage du broker. Ce sont les pannes les plus douloureuses en production.
Puis-je lancer ces vérifications sur un broker de test public ?
Celles de connectivité et de messagerie, oui. Celles d'authentification, d'ACL, de redémarrage et de charge exigent un broker que vous contrôlez, car un sandbox partagé a sa propre configuration ouverte et ne doit pas être stressé.
