Bevor ein MQTT-Broker echte Geräte bedient, arbeite diese MQTT-Broker-Test-Checkliste ab: 25 konkrete Prüfungen, jede mit Befehl und erwartetem Ergebnis. Sie deckt Konnektivität, TLS, Authentifizierung, ACLs, Nachrichtensemantik, Resilienz und Kapazität ab – genau die Bereiche, in denen Produktionsvorfälle tatsächlich beginnen.
Alle Beispiele nutzen die Mosquitto-Kommandozeilen-Clients (mosquitto_pub, mosquitto_sub) und broker.connectmq.com. Ersetze Host, Ports und Zugangsdaten durch die deines Brokers. Sofern nicht anders angegeben, sprechen die Clients MQTT 3.1.1; mit -V mqttv5 testest du das Verhalten von MQTT 5.
export HOST=broker.connectmq.com
export T=testmqtt/checklist-$RANDOM # eindeutiges Topic-Präfix für diesen Lauf
export AUTH="-u $MQTT_USER -P $MQTT_PASS"
export TLS="-p 8883 --capath /etc/ssl/certs"Konnektivität (Prüfungen 1–5)
1. DNS löst auf die erwartete Adresse auf. dig +short $HOST liefert die erwarteten IPs – aus jedem Netz, das deine Clients nutzen (Büro, Cloud-VPC, Mobilfunk-APN).
2. Jeder Listener-Port ist erreichbar. Erwarte succeeded (oder open) für jeden Port, den du freigeben willst, und einen Fehler für alle anderen:
for p in 1883 8883 8083 8084; do nc -zv -w 3 $HOST $p; done3. Ein Client erhält ein CONNACK. mosquitto_pub -h $HOST -t $T/ping -m hi -d gibt Client … received CONNACK (0) aus. Alles andere oder ein Hänger deutet auf ein Firewall-, Proxy- oder Listener-Problem hin.
4. Der WebSocket-Endpunkt macht das Upgrade. Browser brauchen Port 8084 mit Pfad /mqtt. Der Handshake muss mit HTTP/1.1 101 Switching Protocols antworten:
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 -1Verbinde dich danach mit dem Online-MQTT-Client, um zu bestätigen, dass auch ein echter Browser funktioniert.
5. Die Verbindungszeit liegt im Budget. time mosquitto_pub -h $HOST $TLS $AUTH -t $T/ping -m hi über TLS aus der Region deiner Geräte. Lege ein Budget fest (zum Beispiel 1–2 Sekunden im Mobilfunk) und werte alles darüber als Fehlschlag.
TLS und Authentifizierung (Prüfungen 6–11)
6. Zertifikatskette und Hostname lassen sich verifizieren. Erwarte Verify return code: 0 (ok) und ein Ablaufdatum, das Monate entfernt ist:
openssl s_client -connect $HOST:8883 -servername $HOST -verify_return_error </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -enddateEin Fehler hier ist genau das, was Geräte später als certificate verify failed melden. Eine MQTT-TLS-Verbindung testen behandelt jede Variante.
7. Klartext ist dort deaktiviert, wo er es sein soll. Wenn Produktions-Clients TLS nutzen müssen, sollte Port 1883 deines Produktions-Brokers Verbindungen ablehnen (Prüfung 2 muss für 1883 fehlschlagen).
8. Anonyme Clients werden abgewiesen. Ohne Zugangsdaten erwartest du Connection error: Connection Refused: not authorised.
mosquitto_pub -h $HOST $TLS -t $T/anon -m x9. Falsche Passwörter werden abgewiesen. Mit falschem Passwort erwartest du Connection Refused: bad user name or password. (MQTT 5: Reason Code 0x86). Jeden anderen Code schlägst du im MQTT-Reason-Code-Tool nach.
mosquitto_pub -h $HOST $TLS -u "$MQTT_USER" -P wrong-password -t $T/auth -m x10. ACLs blockieren fremde Topics. Melde dich als Geräte-User an und publiziere außerhalb seines Namespace. Unter MQTT 3.1.1 verwirft der Broker die Nachricht stillschweigend – prüfe also mit einem privilegierten Subscriber, dass nichts ankommt. Unter MQTT 5 mit QoS 1 enthält das PUBACK die Ablehnung; die Debug-Ausgabe zeigt RC:135 (0x87 Not authorized):
mosquitto_pub -h $HOST $TLS $AUTH -V mqttv5 -q 1 -d -t other-tenant/secret -m x11. Geräte-User können # nicht abonnieren. mosquitto_sub -h $HOST $TLS $AUTH -t '#' -C 1 -W 5 sollte All subscription requests were denied. ausgeben. Einen vollständigen ACL-Matrix-Test findest du unter MQTT-ACL-Berechtigungen testen.
Nachrichtensemantik (Prüfungen 12–18)
12. Der Publish/Subscribe-Roundtrip funktioniert. Abonnieren, ein eindeutiges Token publizieren, es innerhalb eines Timeouts empfangen. Das Ein-Minuten-Smoke-Test-Skript macht genau das, mit Exit-Code für Erfolg oder Fehlschlag.
13. QoS 1 wird bestätigt. mosquitto_pub -h $HOST -q 1 -d -t $T/qos -m x zeigt received PUBACK. Mit -q 2 erwartest du PUBREC und PUBCOMP.
14. Retained Messages werden gespeichert und gelöscht.
mosquitto_pub -h $HOST -t $T/retained -m on -r -q 1
mosquitto_sub -h $HOST -t $T/retained -C 1 -W 5 -v # gibt den Retained-Wert aus
mosquitto_pub -h $HOST -t $T/retained -r -n # leere Retained-Payload löscht ihn
mosquitto_sub -h $HOST -t $T/retained -C 1 -W 5 -v # Timeout: nichts mehr retained15. Der Last Will wird bei einem unsauberen Disconnect veröffentlicht.
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 $! # simulierter AbsturzDer erste Subscriber gibt …/status offline aus. Ein sauberes DISCONNECT darf ihn nicht auslösen.
16. Persistente Sessions puffern Offline-Nachrichten. Verbinde dich mit fester Client-ID und -c (Clean Session aus), stoppe den Client, publiziere mit QoS 1 und verbinde dich mit demselben Befehl neu – die gepufferte Nachricht kommt an:
mosquitto_sub -h $HOST -i queue-check -c -q 1 -t $T/queue -W 3 # legt die Session an
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. Doppelte Client-IDs verhalten sich wie erwartet. Starte zwei Clients mit derselben -i; der Broker trennt den ersten. Sorge dafür, dass jedes Gerät eine eindeutige ID erzeugt – der Client-ID-Generator hilft –, sonst siehst du endlose Reconnect-Schleifen.
18. Die maximale Nachrichtengröße ist bekannt. Publiziere eine Payload knapp über deiner größten echten Nachricht und prüfe das Verhalten des Brokers. Große MQTT-Payloads testen enthält ein Skript für einen Größen-Sweep.
Resilienz (Prüfungen 19–22)
19. Clients verbinden sich nach einem Broker-Neustart neu. Starte den Broker in Staging neu (docker restart mosquitto oder systemctl restart mosquitto) und bestätige, dass sich jeder Client-Typ ohne manuellen Eingriff neu verbindet, neu abonniert und weiter publiziert.
20. Tote Verbindungen werden erkannt. Verwirf den Traffic zum Broker stillschweigend (sudo iptables -A OUTPUT -p tcp --dport 8883 -j DROP) und prüfe, ob der Client das innerhalb von etwa 1,5 × seinem Keep-Alive-Intervall bemerkt; entferne die Regel danach wieder. Chaos-Tests für MQTT zeigt, wie du das mit tc netem und Toxiproxy automatisierst.
21. Reconnects nutzen Backoff mit Jitter. Nach einem Neustart sollten sich die Verbindungsversuche über mehrere Sekunden verteilen statt in einer einzigen Spitze anzukommen. Prüfe die Client-Logs oder den Verlauf der Verbindungsrate am Broker.
22. Failover funktioniert, falls du einen Cluster betreibst. Stoppe einen Knoten und bestätige, dass die Clients zu einem anderen wechseln, Sessions wie geplant überleben und kein Retained-Zustand verloren geht.
Kapazität und Betrieb (Prüfungen 23–25)
23. Der Broker verkraftet das Doppelte der erwarteten Spitzenlast. Führe einen Lasttest mit deiner echten Payload-Größe, QoS und Topic-Struktur durch – siehe MQTT-Broker-Lasttests – und notiere p99-Latenz und Fehlerrate.
24. Metriken sind sichtbar. Verbundene Clients, Nachrichtenraten und verworfene Nachrichten erscheinen auf einem Dashboard. Bei Mosquitto (sofern erlaubt): mosquitto_sub -h $HOST $AUTH -t '$SYS/broker/clients/connected' -C 1 -v.
25. Alerts lösen tatsächlich aus. Provoziere absichtlich einen: Stoppe einen Test-Client, der immer online sein sollte, oder richte eine Prüfung auf ein bald ablaufendes Zertifikat, und bestätige, dass der Alert bei einem Menschen ankommt.
Die Checkliste als Skript
| Prüfungen | Manueller Aufwand | Automatisierung |
|---|---|---|
| 1–6, 8–9, 12–16 | Minuten | Bash-Skript mit mosquitto_pub/mosquitto_sub, ein Exit-Code pro Prüfung |
| 10–11, 17–18 | Minuten | Dasselbe Skript mit eigenen Test-Usern |
| 19–22 | Stunden | Staging-Job mit geskripteten Neustarts und Netzwerkfehlern |
| 23–25 | Halber Tag | Geplanter Lasttest plus Monitoring-Regeln |
Fang damit an, die schnellen Prüfungen zu skripten, und lass sie in CI und nach jeder Broker-Änderung laufen; die langsamen bleiben auf der Release-Checkliste.
Prüfungen 3, 12 und 14 im Browser ausführen
Ein Broker, der diese 25 Prüfungen besteht, hat bewiesen, worauf es am ersten Tag ankommt: Clients erreichen ihn sicher, nur die richtigen Clients kommen hinein, Nachrichten verhalten sich wie geplant, und Fehler heilen von selbst. Leg die Befehle in dein Repository und führe sie erneut aus, wann immer sich Broker, Konfiguration oder Zertifikate ändern.
Häufig gestellte Fragen
Wie lange dauert es, eine MQTT-Broker-Test-Checkliste abzuarbeiten?
Die Prüfungen zu Konnektivität, Sicherheit und Messaging dauern von Hand unter einer Stunde und als Skript nur Sekunden. Resilienz- und Lastprüfungen brauchen eine Staging-Umgebung und beim ersten Mal meist einen halben Tag.
Welche MQTT-Prüfungen sind vor dem Go-live am wichtigsten?
TLS mit gültigem Zertifikat, abgewiesene anonyme Logins und falsche Passwörter, ACLs, die fremde Topics blockieren, ein funktionierender Last Will und Client-Reconnects nach einem Broker-Neustart. Diese Fehler schmerzen in Produktion am meisten.
Kann ich diese Prüfungen gegen einen öffentlichen Test-Broker laufen lassen?
Die Konnektivitäts- und Messaging-Prüfungen ja. Authentifizierung, ACLs, Neustarts und Last brauchen einen Broker, den du selbst kontrollierst, denn eine geteilte Sandbox hat ihre eigene offene Konfiguration und darf nicht gestresst werden.
