Mosquitto-Cloud-Alternative: Von selbst betriebenem Mosquitto zum verwalteten MQTT-Broker

Nach einer Mosquitto-Cloud-Alternative suchen viele Teams, sobald ihr erster selbst betriebener Mosquitto-Server zu etwas geworden ist, auf das sich Kunden verlassen. Dieser Artikel erklärt, was Sie behalten, was Sie gewinnen und worauf Sie verzichten, wenn Sie von selbst betriebenem Mosquitto auf einen verwalteten MQTT-Broker mit MQTT 3.1.1 und 5.0 umsteigen, und zeigt eine Bridge-Konfiguration, mit der Sie Standort für Standort migrieren.

Warum Mosquitto so beliebt ist

Eclipse Mosquitto hat sich seinen Platz verdient. Er ist Open Source, schlank, gut dokumentiert und läuft auf fast allem, vom Raspberry Pi bis zur großen VM. Er unterstützt MQTT 3.1.1 und 5.0, TLS, WebSockets, Passwortdateien, ACL-Dateien und Bridging. Seine Kommandozeilen-Tools mosquitto_pub und mosquitto_sub sind für viele Ingenieure das Standardwerkzeug, um jeden beliebigen Broker zu testen.

Für ein Labor, ein einzelnes Zuhause oder ein Werksnetz ohne Internetanbindung ist Mosquitto oft alles, was Sie brauchen. Die Frage nach einer Alternative stellt sich erst, wenn der Betriebsaufwand den Komfort überwiegt. Einen breiteren Blick auf das Open-Source-Feld bietet der Vergleich von Open-Source-MQTT-Brokern.

Wo selbst betriebener Mosquitto schwierig wird

Der Broker ist selten das Problem. Die Arbeit drumherum schon:

• Sichere Bereitstellung im Internet. Sie brauchen eine öffentliche IP oder einen DNS-Namen, Firewall-Regeln, TLS-Zertifikate samt Erneuerung und die Gewissheit, dass kein anonymer Listener offen geblieben ist.
• Benutzerverwaltung. mosquitto_passwd und eine ACL-Textdatei funktionieren für zehn Geräte. Bei Hunderten brauchen Sie Provisioning-Skripte und eine Möglichkeit, Zugangsdaten schnell zu widerrufen.
• Monitoring. Sie müssen $SYS-Statistiken oder Logs sammeln, speichern und jemanden alarmieren, wenn Verbindungen abbrechen.
• Upgrades. Major-Upgrades können Standardwerte ändern. Mosquitto 2.0 etwa änderte die Standards für Listener und anonymen Zugriff, was viele bestehende Installationen überraschte.
• Single-Node-Design. Open-Source-Mosquitto läuft als einzelner Broker-Prozess. Fällt diese Maschine aus, sind alle Clients getrennt, bis sie wieder läuft.

Nichts davon ist Kritik an Mosquitto. Es sind schlicht die Kosten, jeden beliebigen Broker selbst zu betreiben, ausführlicher beschrieben unter MQTT-Broker selbst betrieben vs. verwaltet.

Was Sie mit einem verwalteten MQTT-Broker behalten

Da ein verwalteter MQTT-Broker dasselbe Standardprotokoll spricht, lässt sich fast alles übernehmen, was Sie gebaut haben:

• Client-Code. Paho, MQTT.js, PubSubClient, Node-RED und die CLI-Tools von Mosquitto funktionieren unverändert, abgesehen von Host, Port und Zugangsdaten.
• Topic-Struktur. Ihr Topic-Baum zieht unverändert um.
• MQTT-5-Funktionen. Bei ConnectMQ stehen Shared Subscriptions (kostenpflichtige Tarife), Retained Messages, Session Expiry, Topic-Aliase, Message Expiry, Response Topics und Reason Codes zur Verfügung.
• Ihre gewohnten Werkzeuge. Sie können weiterhin mosquitto_sub zum Debuggen verwenden.

Was Sie gewinnen

• Kein Server zu betreiben. TLS auf 8883 und Secure WebSocket auf 8084 mit einem Let's-Encrypt-Zertifikat sind vom ersten Tag an bereit.
• Zugangsdaten aus einem Portal statt Passwortdateien. Jeder Broker erhält einen generierten Benutzernamen, ein Passwort und eine Client-ID.
• Eingebaute Transparenz. Das ConnectMQ-Portal enthält einen MQTT-Client im Browser, einen Live-Topic-Explorer, ein Dashboard und Schwellwert-Alarmregeln, sodass Sie den Datenverkehr ohne zusätzliche Tools sehen.
• Schutzmechanismen, die Sie sonst selbst bauen müssten, etwa tarifabhängige Kontingente, Flood-Schutz und IP-Sperren nach wiederholt fehlgeschlagenen Anmeldungen.
• Industrielle Extras, falls relevant: Erkennung von Topics eines Unified Namespace (UNS), deren Struktur der ISA-95-Hierarchie folgt, und Dekodierung von Sparkplug-B-Payloads.

Worauf Sie verzichten

Seien Sie vor der Migration ehrlich bei den Kompromissen:

Sind ACLs pro Topic oder eigene Plugins zentral für Ihr Design, behalten Sie Mosquitto am Edge und nutzen Sie den Cloud-Broker für die Teile, die davon profitieren.

Fragen, die Sie zuerst im Team klären sollten

Bevor Sie Anbieter vergleichen, einigen Sie sich intern auf einige Punkte. Welche Geräte müssen weiterlaufen, wenn die Internetverbindung ausfällt? Wer betreut den Mosquitto-Server derzeit, und womit würde diese Person ihre Zeit lieber verbringen? Welche Topics transportieren Befehle, die physische Anlagen verändern, und wer sollte darin veröffentlichen dürfen? Wie viele gleichzeitige Verbindungen erwarten Sie in einem Jahr, nicht nur heute? Die Antworten entscheiden, ob Sie einen reinen Cloud-Broker, eine Hybridlösung mit lokalem Edge-Broker oder eine dedizierte Bereitstellung brauchen, und sie halten die Bewertung auf Ihre Anforderungen statt auf Funktionslisten fokussiert.

Eine Mosquitto-Cloud-Alternative bewerten

Unabhängig vom Anbieter sollten Sie folgende Punkte anhand der aktuellen Dokumentation prüfen:

1. Protokollversionen. Werden MQTT 3.1.1 und 5.0 unterstützt, einschließlich der MQTT-5-Funktionen, die Sie nutzen?
2. Ports und Transporte. TLS auf 8883, WebSocket und Secure WebSocket für Browser-Anwendungen.
3. QoS-Stufen und Nachrichtengrößen in dem Tarif, den Sie tatsächlich kaufen würden.
4. Verhalten von Retained Messages und Session Expiry.
5. Authentifizierungsmodell. Benutzername und Passwort, Client-Zertifikate oder beides.
6. Kostenloser Tarif. Können Sie mit echten Geräten testen, bevor Sie zahlen?
7. Bereitstellungsmodelle. Geteilt, dediziert, in Ihrer eigenen Cloud oder selbst verwaltet.
8. Ausstiegsweg. Können Sie wechseln, ohne die Geräte-Firmware neu zu schreiben? Der Artikel zum MQTT-Vendor-Lock-in erklärt, worauf Sie achten sollten.

Schrittweise Migration mit einer Mosquitto-Bridge

Sie müssen nicht alles auf einmal umstellen. Mit der Bridge-Funktion von Mosquitto lassen sich ausgewählte Topics von Ihrem bestehenden Server an einen verwalteten MQTT-Broker weiterleiten. Ergänzen Sie Ihre mosquitto.conf (Mosquitto 2.x) um Folgendes:

# Lokalen Mosquitto per TLS mit einem ConnectMQ-Broker verbinden
connection connectmq-bridge
address broker.connectmq.com:8883
bridge_protocol_version mqttv50
bridge_capath /etc/ssl/certs
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
cleansession false
restart_timeout 10 60

# Werkstelemetrie in die Cloud senden, Befehle zurück empfangen
topic plant1/+/+/telemetry out 1
topic plant1/+/+/cmd in 1

Starten Sie Mosquitto neu und prüfen Sie im Log, ob die Bridge-Verbindung erfolgreich ist:

sudo systemctl restart mosquitto
sudo journalctl -u mosquitto -n 50 --no-pager

Prüfen Sie anschließend, ob die Daten in der Cloud ankommen, indem Sie mit den Broker-Zugangsdaten abonnieren:

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID-debug \
  -t "plant1/#" -v

Beachten Sie, dass der verwaltete MQTT-Broker Client-IDs an die ausgegebenen Zugangsdaten bindet. Verwenden Sie für eine zweite gleichzeitige Verbindung wie diese Debug-Session daher eine Client-ID, die Ihnen dafür ausgestellt wurde, oder nutzen Sie stattdessen den Browser-Client im Portal.

Mit dem Bridge-Muster können Dashboards und Remote-Nutzer auf den Cloud-Broker umziehen, während lokale Geräte weiterhin mit der vertrauten Mosquitto-Instanz kommunizieren. Sobald Sie sicher sind, können Sie die Geräte direkt auf den verwalteten MQTT-Broker umstellen. Den vollständigen Ablauf beschreibt Mosquitto in die Cloud migrieren.

In Werken lohnt es sich, die Migration für eine saubere Topic-Struktur zu nutzen. Statt plant1/+/+/telemetry bildet ein Unified Namespace die ISA-95-Ebenen Enterprise → Site → Area → Line → Cell direkt im Topic ab, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Die Bridge leitet dann ganze Bereiche oder Linien gezielt weiter, und MES, SCADA und Cloud-Anwendungen finden die Daten an derselben Stelle. Mehr dazu im Beitrag zu Sparkplug B und Unified Namespace.

Fehlerbehebung bei der Bridge

• Die Bridge verbindet sich und bricht immer wieder ab. Ein anderer Client verwendet dieselbe Client-ID. Jede Verbindung braucht ihre eigene ID.
• TLS-Handshake-Fehler. Stellen Sie sicher, dass bridge_capath auf den System-CA-Speicher zeigt, oder verwenden Sie bridge_cafile mit einem Bundle, das die Let's-Encrypt-Kette enthält.
• Nachrichten werden nicht weitergeleitet. Prüfen Sie Topic-Muster und Richtung (out sendet von lokal nach remote, in empfängt von remote nach lokal).
• QoS 2 wird abgelehnt. Die kostenlosen Serverless-Tarife unterstützen QoS bis 1; betreiben Sie die Bridge also mit QoS 1 oder wechseln Sie den Tarif.

Einen verwalteten MQTT-Broker parallel zu Mosquitto testen

Sie können die verwaltete Seite testen, ohne die Produktion anzufassen. Erstellen Sie einen kostenlosen Serverless-Broker bei ConnectMQ ohne Kreditkarte, fügen Sie den obigen Bridge-Block in eine Test-Instanz von Mosquitto ein und beobachten Sie, wie Ihre Topics im Live-Topic-Explorer erscheinen. Für ein tieferes Verständnis der Optionen lesen Sie den Leitfaden zum Cloud-MQTT-Broker oder erfahren Sie, was Ihnen ein verwalteter MQTT-Broker abnimmt. Mehr zur Plattform finden Sie auf connectmq.com.

Häufig gestellte Fragen

Gibt es eine gehostete Version von Mosquitto?

Einige Anbieter bieten gehosteten oder kommerziell unterstützten Mosquitto an. Alternativ funktioniert jeder standardkonforme verwaltete MQTT-Broker mit Mosquitto-Clients und -Bridges, da das Protokoll dasselbe ist.

Funktionieren meine Mosquitto-Clients mit einem verwalteten MQTT-Broker?

Ja. Clients, die MQTT 3.1.1 oder 5.0 sprechen, brauchen nur einen neuen Host, Port, neue Zugangsdaten und eine Client-ID.

Kann ich Mosquitto am Edge behalten und zusätzlich die Cloud nutzen?

Ja. Eine Bridge leitet ausgewählte Topics von einem lokalen Mosquitto an den Cloud-Broker weiter, ein gängiges Muster für Werke und Standorte mit unzuverlässiger Verbindung.

Verliere ich meine ACLs, wenn ich von Mosquitto wegwechsle?

Das hängt vom Anbieter ab. ConnectMQ isoliert Mandanten und bindet Client-IDs an Zugangsdaten, bietet aber keine ACLs pro Topic. Wenn Sie darauf angewiesen sind, behalten Sie Mosquitto am Edge.