MQTT $SYS Topics: Was System-Topics des Brokers verraten

MQTT SYS Topics sind der $SYS/...-Zweig des Topic-Baums, in dem ein Broker Informationen über sich selbst statt Anwendungsdaten veröffentlicht. In diesem Artikel erfahren Sie, woher die Konvention stammt, warum eine einfache #-Subscription sie nie anzeigt, was ein typischer Broker dort bereitstellt und wie Sie das eine System-Topic, das ConnectMQ veröffentlicht, nutzen, um den Verbindungsstatus von Clients zu verfolgen.

Was sind MQTT SYS Topics?

Die MQTT-Spezifikation reserviert Topics, die mit $ beginnen, für brokerspezifische Zwecke. Clients sollen darunter keine Anwendungsdaten veröffentlichen, und die Spezifikation überlässt den Inhalt vollständig der Implementierung. Im Laufe der Jahre hat sich $SYS/ als De-facto-Präfix für Broker-Telemetrie etabliert: Uptime, Version, Anzahl verbundener Clients, Nachrichten- und Byte-Zähler und ähnliche Verwaltungsdaten.

Das entscheidende Wort ist „de facto“. Es gibt keine Standardliste von $SYS-Topics, kein Standardformat für Payloads und keine Garantie, dass ein bestimmter Broker überhaupt eines davon veröffentlicht. Mosquitto hat einen umfangreichen Baum populär gemacht, andere Broker veröffentlichen eine Teilmenge oder ein anderes Layout, und viele verwaltete MQTT-Broker ersetzen das meiste davon durch Dashboards und APIs. Betrachten Sie jedes $SYS-Topic als Implementierungsdetail des konkreten Brokers, mit dem Sie verbunden sind.

Warum eine #-Subscription sie nicht anzeigt

Das überrascht beim ersten Mal fast jeden. Wenn Sie # abonnieren, erhalten Sie jede Anwendungsnachricht auf dem Broker, aber nichts aus $SYS. Das ist so gewollt. Die MQTT-Spezifikation auf mqtt.org legt fest, dass ein Topic-Filter, der mit einer Wildcard (# oder +) beginnt, keine Topic-Namen matchen darf, die mit $ beginnen.

Die Regel schützt gewöhnliche „Catch-all“-Subscriber davor, mit Broker-Statistiken überflutet zu werden, und verhindert, dass Tools, die # spiegeln, versehentlich Systemdaten erneut veröffentlichen. Um System-Topics zu lesen, müssen Sie das Präfix $SYS explizit angeben:

#                  -> nur Anwendungs-Topics, nie $SYS
$SYS/#             -> alles unter $SYS (sofern der Broker es erlaubt)
$SYS/broker/+/+    -> eine bestimmte Tiefe unter $SYS/broker
+/broker/uptime    -> matcht NICHT $SYS/broker/uptime

Dieselbe Logik gilt für die Wildcard-Regeln für MQTT-Topics im Allgemeinen: Wildcards arbeiten Ebene für Ebene, und die führende $-Ebene ist an erster Position schlicht vom Wildcard-Matching ausgenommen.

Ein typischer $SYS-Baum (Beispiel Mosquitto)

Mosquitto ist die gängigste Referenz und daher gut geeignet, um zu sehen, was System-Topics enthalten können. In der Standardkonfiguration veröffentlicht er alle paar Sekunden einen Schnappschuss seiner Zähler. Das Intervall wird in mosquitto.conf gesteuert:

# mosquitto.conf
# $SYS-Updates alle 10 Sekunden veröffentlichen (0 deaktiviert periodische Updates)
sys_interval 10

Eine Auswahl der Topics, die Sie auf einer lokalen Mosquitto-Instanz sehen:

Um sie auf Ihrem eigenen Mosquitto-Broker zu beobachten, setzen Sie das Topic in Anführungszeichen, damit Ihre Shell $SYS nicht expandiert:

mosquitto_sub -h localhost -p 1883 -i sys-watcher-01 -t '$SYS/#' -v

Die meisten Werte werden als Retained Messages veröffentlicht, sodass ein neuer Subscriber sofort den neuesten Schnappschuss erhält, statt auf das nächste Intervall zu warten. Die Zähler werden beim Neustart des Brokers zurückgesetzt, was für Diagramme wichtig ist: Ein Abfall auf null bedeutet einen Neustart, keine ruhige Stunde.

Häufige Fallstricke mit $SYS-Daten

• Portabilität voraussetzen. Ein Dashboard, das auf den $SYS-Topics von Mosquitto aufbaut, bricht in dem Moment, in dem Sie zu einem anderen Broker wechseln. Halten Sie die Parsing-Logik an einer Stelle.
• Die Shell vergessen. In bash expandiert "$SYS/#" in doppelten Anführungszeichen $SYS zu einer leeren Variable, und Sie abonnieren /#. Verwenden Sie einfache Anführungszeichen.
• Öffentlich zugänglich machen. Auf einem selbst betriebenen Broker verraten System-Topics Client-Zahlen und Versionsnummern. Schränken Sie sie über die Autorisierungsregeln Ihres Brokers ein, wenn der Broker aus dem Internet erreichbar ist.
• Zu schnelles Abfragen. Ein sehr kurzes sys_interval erzeugt Verkehr mit wenig Nutzen. Zehn bis sechzig Sekunden reichen für Betriebsdiagramme völlig.

MQTT SYS Topics auf einem verwalteten MQTT-Broker

Auf einem verwalteten MQTT-Broker brauchen Sie meist keinen großen $SYS-Baum, weil der Betreiber Broker-Metriken bereits erfasst und Ihnen anzeigt. Diesen Ansatz verfolgt ConnectMQ. Informationen auf Broker-Ebene wie Verbindungen und Verkehr werden im Dashboard des Portals dargestellt, und der Live-Topic-Explorer zeigt, welche Topics aktiv sind; es ist also nicht nötig, Zähler aus System-Topics zu parsen.

ConnectMQ veröffentlicht genau ein System-Topic:

$SYS/broker/connection/{clientId}/state

Es meldet den Verbindungsstatus einer bestimmten Client-ID. Das ist genau der Teil der $SYS-Daten, den Anwendungscode tatsächlich braucht: „Ist Gerät X gerade online?“ Alles andere, etwa Client-Zahlen und Nachrichtenraten, gehört ins Monitoring und nicht in Ihren MQTT-Datenfluss.

Den Verbindungsstatus eines Clients beobachten

Das folgende Beispiel nutzt Python paho-mqtt 2.x, um das Status-Topic eines Geräts auf Ihrem privaten Broker zu abonnieren. Ersetzen Sie die Platzhalter durch die im Portal generierten Zugangsdaten und setzen Sie DEVICE_ID auf die Client-ID des Geräts, das Sie beobachten möchten.

import ssl
import paho.mqtt.client as mqtt

BROKER = "YOUR_BROKER_HOST"      # wird im Portal angezeigt
PORT = 8883
DEVICE_ID = "YOUR_DEVICE_CLIENT_ID"
STATE_TOPIC = f"$SYS/broker/connection/{DEVICE_ID}/state"

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print(f"Connect failed: {reason_code}")
        return
    print("Connected, subscribing to", STATE_TOPIC)
    client.subscribe(STATE_TOPIC, qos=1)

def on_subscribe(client, userdata, mid, reason_code_list, properties):
    for rc in reason_code_list:
        print("SUBACK:", rc)

def on_message(client, userdata, msg):
    print(f"{msg.topic} -> {msg.payload.decode(errors='replace')}")

client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id="YOUR_CLIENT_ID",
    protocol=mqtt.MQTTv5,
)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_subscribe = on_subscribe
client.on_message = on_message

client.connect(BROKER, PORT, keepalive=60)
client.loop_forever()

Starten Sie das Skript und schalten Sie dann das Gerät aus und wieder ein oder beenden Sie seinen Client. Sie sehen, wie sich das Status-Topic ändert, wenn das Gerät sich trennt und neu verbindet. Bevor Sie Parsing-Logik schreiben, sehen Sie sich die tatsächliche Payload im MQTT-Client im Browser des Portals an, damit Ihr Code zu dem passt, was der Broker sendet, und nicht zu dem, was Sie vermuten.

$SYS-Status oder Last Will

Vielleicht verfolgen Sie die Präsenz bereits mit einer Last-Will-and-Testament-Nachricht. Die beiden Ansätze ergänzen sich:

Ein sinnvolles Muster: Behalten Sie den Last Will für Anwendungs-Consumer, die Ihren Topic-Baum bereits verstehen, und nutzen Sie das Status-Topic des Brokers für Betriebswerkzeuge und um zu prüfen, ob sich Geräte ohne Will korrekt verhalten. Der Leitfaden zum Online-Status von MQTT-Geräten erläutert das Will-basierte Muster im Detail.

In einem Unified Namespace (UNS) nach ISA-95 veröffentlichen viele Teams den Gerätestatus zusätzlich im Anwendungsbaum, etwa unter acme/werk-stuttgart/montage/linie-1/gateway-1/status. So finden MES, Leitstand und Dashboards die Präsenz eines Edge-Gateways an derselben Stelle wie dessen Maschinendaten, und das Status-Topic des Brokers dient als unabhängige Gegenprobe.

Monitoring-Checkliste ohne großen $SYS-Baum

Wenn Sie von einem selbst betriebenen Broker kommen, bei dem Grafana-Diagramme aus $SYS gespeist wurden, decken Sie dieselben Anforderungen auf einem verwalteten MQTT-Broker so ab:

1. Verbindungszahlen und Verkehr. Nutzen Sie das Broker-Dashboard im Portal statt $SYS/broker/clients/connected.
2. Welche Topics aktiv sind. Nutzen Sie den Live-Topic-Explorer, statt vom Laptop aus # zu abonnieren.
3. Präsenz pro Gerät. Abonnieren Sie $SYS/broker/connection/{clientId}/state für die Client-IDs, die Sie interessieren, oder verwenden Sie einen Last Will.
4. Schwellenwerte für Daten. Konfigurieren Sie im Portal Alarmregeln für Werte wie Temperatur oder Druck und prüfen Sie das Alarmprotokoll.
5. Langfristige Metrikhistorie. Betreiben Sie einen eigenen Subscriber (Telegraf, einen kleinen Python-Dienst oder Node-RED), der die benötigten Daten in Ihre Zeitreihendatenbank schreibt.
6. Kontingente im Blick behalten. Achten Sie in Client-Logs auf den MQTT-5-Reason-Code 0x97 (Quota exceeded); er zeigt an, dass ein Tariflimit erreicht wurde.

Auf dem öffentlichen MQTT-Broker testen

Wenn Sie nur mit der Topic-Struktur experimentieren möchten, akzeptiert der öffentliche MQTT-Broker unter broker.connectmq.com anonyme Verbindungen mit jeder nicht leeren, eindeutigen Client-ID. Denken Sie daran, dass er für Tests gedacht und für alle lesbar ist; verwenden Sie also ein eindeutiges Präfix und senden Sie niemals sensible Daten:

# Terminal 1: das eigene Demo-Präfix abonnieren
mosquitto_sub -h broker.connectmq.com -p 1883 -i sys-demo-sub-7f3a \
  -t 'connectmq/demo/7f3a/#' -v

# Terminal 2: eine Testnachricht veröffentlichen
mosquitto_pub -h broker.connectmq.com -p 1883 -i sys-demo-pub-7f3a \
  -t 'connectmq/demo/7f3a/hello' -m 'hi'

Beachten Sie, dass die #-Subscription in Terminal 1 Ihre Nachricht sieht, aber nichts unter $SYS, genau wie es die Spezifikation verlangt. Für einen breiteren Überblick, wie Topics, Subscriptions und der Broker zusammenspielen, ist das MQTT-Tutorial eine gute nächste Lektüre, und MQTT Topic-Namenskonventionen zeigt, wie Sie Ihren eigenen Baum so aufgeräumt halten wie den Systembaum eines Brokers.

Mit ConnectMQ starten

Sie möchten Broker-Metriken, ohne $SYS-Zähler zu parsen? Erstellen Sie einen kostenlosen Serverless-Broker unter app.connectmq.com, ohne Kreditkarte. In wenigen Minuten erhalten Sie generierte Zugangsdaten, ein Dashboard, einen Live-Topic-Explorer und das Topic $SYS/broker/connection/{clientId}/state für die Präsenz pro Gerät.

Häufig gestellte Fragen

Warum zeigt eine Subscription auf # keine $SYS-Nachrichten?

Laut MQTT-Spezifikation dürfen Topic-Filter, die mit einer Wildcard beginnen, keine Topics matchen, die mit $ beginnen. Abonnieren Sie $SYS/# explizit, wenn Ihr Broker System-Topics veröffentlicht und Ihnen erlaubt, sie zu lesen.

Sind MQTT SYS Topics standardisiert?

Nein. Standardisiert ist nur die Reservierung von Topics mit $-Präfix. Topic-Namen, Payloads und Aktualisierungsintervalle unterscheiden sich zwischen Brokern, Code zum Auslesen ist also brokerspezifisch.

Welches $SYS-Topic veröffentlicht ConnectMQ?

ConnectMQ veröffentlicht $SYS/broker/connection/{clientId}/state, das den Verbindungsstatus eines Clients meldet. Broker-Metriken wie Verbindungen und Verkehr werden stattdessen im Dashboard des Portals angezeigt.

Kann ich eigene Nachrichten auf $SYS-Topics veröffentlichen?

Das sollten Sie nicht. Das Präfix $ ist für den Broker reserviert, und die meisten Broker lehnen Client-Publishes dort ab oder ignorieren sie. Legen Sie Ihre eigenen Statusdaten in Ihrem Anwendungs-Topic-Baum ab.