MQTT Broker Monitoring sagt Ihnen, ob Nachrichten fließen, bevor Ihre Kunden Ihnen sagen, dass sie es nicht tun. Dieser Leitfaden behandelt die Metriken, auf die es wirklich ankommt – Verbindungen, Nachrichtenraten, verworfene Nachrichten, Latenz und Anzahl der Retained Messages –, zeigt, wie Sie daraus Alarme ohne Rauschen machen, und wie Sie eine einfache Ende-zu-Ende-Probe bauen. Außerdem sehen Sie, wie Sie einen Broker im ConnectMQ-Portal beobachten.
Warum Broker-Monitoring anders ist
Der Ausfall eines Webservers ist meist laut: Requests schlagen fehl und Fehlerraten schnellen hoch. MQTT-Fehler sind oft still. Ein Subscriber kann verbunden bleiben, aber nichts mehr empfangen, weil seine Subscription nach einem Reconnect ohne persistente Sitzung verloren ging. Geräte können verbunden sein, aber nichts publizieren, weil ein Sensortreiber hängt oder ein Edge-Gateway die Verbindung zur SPS verloren hat. Eine Warteschlange für einen Offline-Client kann unbemerkt wachsen, bis Limits erreicht sind.
Gutes Monitoring kombiniert daher drei Sichten:
- Broker-seitige Metriken: was der Broker sieht, etwa Verbindungen, Durchsatz und verworfene Nachrichten.
- Client-seitige Metriken: was Geräte und Anwendungen sehen, etwa fehlgeschlagene Verbindungen und Reconnect-Zähler.
- Ende-zu-Ende-Proben: ein synthetischer Client, der publiziert und empfängt und so misst, ob das System als Ganzes funktioniert.
Wenn Ihnen die einzelnen Bausteine neu sind, beginnen Sie damit, was ein MQTT-Broker tut.
Die entscheidenden Metriken für das MQTT Broker Monitoring
| Metrik | Was sie Ihnen sagt | Typischer Alarm |
|---|---|---|
| Verbundene Clients | Zustand der Flotte, Ausfälle, Connect-Stürme | Plötzlicher Einbruch oder Anstieg gegenüber der Baseline |
| Verbindungsversuche und -fehler | Probleme mit Zugangsdaten, Angriffe, Limits | Fehlerrate über dem Normalwert |
| Empfangene Nachrichten pro Sekunde | Publish-Aktivität | Abfall nahe null bei einer bekanntermaßen aktiven Flotte |
| Gesendete Nachrichten pro Sekunde | Zustellung an Subscriber | Abweichung vom erwarteten Fan-out |
| Verworfene oder abgelehnte Nachrichten | Volle Warteschlangen, Größen- oder Quotenlimits | Jede anhaltende Rate ungleich null |
| Inflight- und wartende Nachrichten | Langsame oder Offline-Konsumenten | Stetiges Wachstum |
| Ende-zu-Ende-Latenz | Für Nutzer sichtbare Verzögerung | Mehrere Minuten über Ihrem Zielwert |
| Anzahl der Retained Messages | Topic-Hygiene, Speicherwachstum | Unerwartetes Wachstum |
| Anzahl der Subscriptions | Lecks im Client-Code | Stetiges Wachstum ohne neue Clients |
| Ressourcenverbrauch (selbst gehostet) | CPU, Arbeitsspeicher, File Descriptors | Annäherung an Limits |
Verbindungen
Die Zahl der verbundenen Clients ist der Herzschlag Ihrer Flotte. Erfassen Sie sie als Zeitreihe und lernen Sie ihren Tagesverlauf kennen. Ein steiler Absturz bedeutet einen Ausfall, ein Netzwerkproblem oder ein abgelaufenes Zertifikat. Ein Sägezahnmuster aus Einbrüchen und Erholungen bedeutet meist, dass Clients wiederholt getrennt werden, oft durch doppelte Client IDs oder einen zu kurzen Keepalive in instabilen Netzen.
Nachrichtenraten
Empfangs- und Senderaten zeigen, ob Daten fließen. Bei einer Flotte, die jede Minute meldet, sollte die Empfangsrate grob vorhersehbar sein. In der Fertigung folgt sie oft dem Schichtmodell: Eine Linie, die nachts stillsteht, darf leiser sein, eine laufende Schicht ohne Maschinendaten dagegen nicht. Vergleichen Sie gesendete mit empfangenen Nachrichten: Das Verhältnis spiegelt den Fan-out wider, eine plötzliche Änderung bedeutet also, dass Subscriber verschwunden oder hinzugekommen sind.
Verworfene und abgelehnte Nachrichten
Broker verwerfen oder lehnen Nachrichten aus konkreten Gründen ab: Payload zu groß, Quote überschritten, Warteschlange für einen langsamen Konsumenten voll oder QoS-0-Nachrichten an einen Client, der nicht hinterherkommt. In MQTT 5 sind viele davon für den Client als Reason Codes sichtbar, etwa 0x97 (Quota exceeded). Protokollieren Sie Reason Codes auf der Client-Seite; sie sind oft die schnellste verfügbare Diagnose.
Latenz
Latenz ist das, was Nutzer spüren. Messen Sie sie Ende zu Ende: Versehen Sie eine Nachricht beim Publisher mit einem Zeitstempel und vergleichen Sie beim Eintreffen am Subscriber. Erfassen Sie Perzentile, nicht nur Durchschnittswerte, denn ein gesunder Median kann einen langen Ausläufer verbergen. Auch die Region spielt eine Rolle; siehe MQTT-Broker-Latenz nach Region.
Retained Messages und Subscriptions
Retained Messages und Subscriptions sollten Ihrem Topic-Design folgen. In einem Unified Namespace (UNS) nach ISA-95 ist das besonders gut prüfbar: Jede Linie und jede Zelle hat einen festen Platz im Topic-Baum, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/status, sodass Sie erwartete und tatsächlich vorhandene Topics vergleichen können. Unbegrenztes Wachstum deutet meist auf einen Bug hin, etwa dynamische Topic-Namen mit Zeitstempeln oder Clients, die bei jedem Reconnect erneut abonnieren.
Client-seitige Metriken nicht vergessen
Der Broker sieht nur, was bei ihm ankommt. Geräte und Backend-Services sollten ihren eigenen Zustand melden: wie viele Verbindungsversuche fehlgeschlagen sind und warum, wie oft sie sich neu verbunden haben, wie viele Messwerte im Offline-Puffer liegen und welche Reason Codes bei CONNACK, PUBACK und DISCONNECT zurückkamen. Publizieren Sie alle paar Minuten eine kompakte Statusmeldung auf einem Status-Topic, als Retained Message, damit Dashboards immer den neuesten Wert zeigen. Wenn ein Standort verstummt, erklären diese letzten Meldungen oft die Ursache, bevor jemand vor Ort ist.
Selbst gehostete Broker: woher die Metriken kommen
Wenn Sie Ihren eigenen Broker betreiben, stammen die Metriken vom Broker selbst. Mosquitto beispielsweise veröffentlicht Statistiken auf $SYS/-Topics wie $SYS/broker/clients/connected und $SYS/broker/messages/received. Geclusterte Broker stellen meist HTTP-APIs oder Metrik-Endpunkte zum Scrapen bereit. Diese binden Sie dann in Ihr Monitoring-System ein, bauen Dashboards, definieren Alarme und ergänzen Host-Metriken wie CPU, Arbeitsspeicher und offene File Descriptors. Die Mosquitto-Dokumentation listet die verfügbaren $SYS-Topics auf.
Eine Ende-zu-Ende-Latenzprobe bauen
Unabhängig vom eingesetzten Broker ist eine synthetische Probe die wertvollste einzelne Prüfung. Sie verbindet sich als normaler Client, publiziert eine Nachricht mit Zeitstempel auf ein privates Topic, empfängt sie zurück und erfasst die Round-Trip-Zeit. Diese Python-Probe nutzt paho-mqtt 2.x und läuft in der vorliegenden Form gegen den Öffentlichen MQTT-Broker, der nur für Tests und Prototypen gedacht ist; für die Produktion wechseln Sie auf die Zugangsdaten Ihres privaten Brokers und 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 # Sekunden zwischen den Proben
ALERT_MS = 500 # Alarmschwelle für die Round-Trip-Zeit
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}")
# Produktion: 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()
Führen Sie die Probe aus den Netzen aus, die Ihre Geräte nutzen, nicht nur aus Ihrem Rechenzentrum, und leiten Sie ihre Alarme an Ihr Paging- oder Chat-Tool weiter.
Aus Metriken nützliche Alarme machen
Alarmmüdigkeit tötet jedes Monitoring. Einige Faustregeln:
- Auf Symptome alarmieren, nicht auf Ursachen. „Probe seit drei Minuten fehlgeschlagen" ist umsetzbar; „CPU bei 70 %" meist nicht.
- Baselines nutzen. Vergleichen Sie Verbindungszahlen mit derselben Stunde der Vorwoche statt mit einem festen Wert.
- Dauer voraussetzen. Lösen Sie erst aus, wenn ein Zustand mehrere Minuten anhält, um kurze Aussetzer abzufangen.
- Warnung und Paging trennen. Langsames Wachstum wartender Nachrichten ist ein Ticket; null Nachrichten von einer aktiven Flotte ist ein Page.
- Die Wächter überwachen. Alarmieren Sie, wenn die Probe selbst nicht mehr meldet.
Monitoring mit ConnectMQ
Bei einem verwalteten MQTT-Broker überwacht der Anbieter die Infrastruktur, Sie brauchen aber trotzdem Einblick in Ihren eigenen Verkehr. ConnectMQ bietet Ihnen im Portal mehrere Werkzeuge:
- Dashboard mit einem Überblick über Ihren Broker.
- Live-Topic-Explorer, um eintreffende Nachrichten in Echtzeit zu verfolgen und verstummte Topics zu erkennen.
- MQTT-Client im Browser, um für schnelle Prüfungen zu publizieren und zu abonnieren, ohne etwas zu installieren.
- Geräteansicht, die Anlagen nach ISA-95-Ebenen ordnet, nützlich für industrielle Flotten. Spiegeln diese Ebenen die Topic-Struktur Ihres UNS wider (Enterprise, Site, Area, Line, Cell), sehen Sie sofort, an welcher Linie oder in welcher Zelle Daten fehlen; mehr zum Konzept unter Sparkplug B und Unified Namespace.
- Schwellenwert-Alarmregeln und Alarmprotokoll, damit Werte außerhalb des zulässigen Bereichs Alarme auslösen, die Sie später nachvollziehen können.
Für den Verbindungsstatus einzelner Geräte veröffentlicht der Broker den Verbindungszustand auf $SYS/broker/connection/{clientId}/state. Ein Backend-Service kann das State-Topic für wichtige Clients wie Gateways abonnieren und reagieren, wenn einer offline geht. Zusammen mit Last-Will-Nachrichten Ihrer Geräte und der obigen Probe deckt das sowohl den Zustand auf Broker- als auch auf Anwendungsebene ab. Außerhalb des Portals sind die ConnectMQ-Erweiterung für VS Code und der Desktop-MQTT-Explorer praktisch, um Verkehr während der Entwicklung zu untersuchen.
Starten Sie mit ConnectMQ
Legen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker an, ganz ohne Kreditkarte, und verfolgen Sie Ihre ersten Nachrichten innerhalb weniger Minuten im Live-Topic-Explorer. Kombinieren Sie ihn anschließend mit der obigen Probe und der MQTT-Produktions-Checkliste, bevor Sie live gehen. Der Leitfaden zum Cloud-MQTT-Broker deckt den Rest des Hosting-Themas ab.
Häufig gestellte Fragen
Was ist die wichtigste Metrik eines MQTT-Brokers?
Die Zahl verbundener Clients in Kombination mit einer Ende-zu-Ende-Probe. Zusammen zeigen sie, ob Geräte online sind und ob Nachrichten tatsächlich fließen.
Wie messe ich die MQTT-Latenz?
Publizieren Sie eine Nachricht mit Zeitstempel und berechnen Sie die Differenz, wenn ein Subscriber sie empfängt. Verfolgen Sie Perzentile über die Zeit und führen Sie Proben aus den Netzen Ihrer Geräte aus.
Warum fallen meine Verbindungszahlen in einem Sägezahnmuster ab und erholen sich wieder?
Häufige Ursachen sind doppelte Client IDs, die sich gegenseitig hinauswerfen, für das Netz zu kurze Keepalive-Intervalle oder ein geräteseitiger Watchdog, der Clients neu startet.
Brauche ich bei einem verwalteten MQTT-Broker trotzdem Monitoring?
Ja. Der Anbieter überwacht seine Infrastruktur, doch nur Sie wissen, was Ihre Geräte senden sollten. Überwachen Sie daher Ihren eigenen Verkehr und ergänzen Sie eine synthetische Probe.
