Ein MQTT Broker SLA ist die schriftliche Zusage eines Anbieters zur Verfügbarkeit, und das Kleingedruckte zählt ebenso viel wie der Prozentwert in der Überschrift. Dieser Artikel übersetzt gängige Verfügbarkeitsziele in reale Ausfallminuten, erklärt, was SLAs üblicherweise abdecken und ausschließen, und zeigt, wie Sie Geräte und Anwendungen so gestalten, dass sie die Ausfallzeit, die jedes SLA weiterhin zulässt, souverän verkraften.
Was ein SLA ist und was nicht
Ein Service Level Agreement ist ein vertragliches Dokument. Es definiert ein messbares Ziel, meist die monatliche Verfügbarkeit, wie diese gemessen wird und was der Anbieter Ihnen schuldet, wenn das Ziel verfehlt wird. Drei verwandte Begriffe werden oft verwechselt:
- SLI (Service Level Indicator): der gemessene Wert, etwa der Anteil erfolgreicher Verbindungsversuche.
- SLO (Service Level Objective): das interne Ziel, das ein Team anstrebt, oft strenger als das SLA.
- SLA (Service Level Agreement): das externe, vertragliche Versprechen mit Konsequenzen, meist Service-Gutschriften.
Der entscheidende Punkt: Ein SLA verhindert keine Ausfälle. Es legt fest, wie viel Nichtverfügbarkeit akzeptabel ist und wie Sie entschädigt werden, wenn es mehr wird. Ihr System muss die vom SLA erlaubte Ausfallzeit trotzdem verkraften.
Verfügbarkeitsprozente in Ausfallminuten
Die Unterschiede zwischen den „Neunen" sind größer, als sie aussehen. Die Tabelle rechnet mit einem durchschnittlichen Monat von etwa 30,4 Tagen und einem Jahr mit 365 Tagen.
| Verfügbarkeit | Ausfallzeit pro Monat | Ausfallzeit pro Jahr |
|---|---|---|
| 99 % | ca. 7 Stunden 18 Minuten | ca. 3 Tage 15,6 Stunden |
| 99,5 % | ca. 3 Stunden 39 Minuten | ca. 1 Tag 19,8 Stunden |
| 99,9 % | ca. 43,8 Minuten | ca. 8,8 Stunden |
| 99,95 % | ca. 21,9 Minuten | ca. 4,4 Stunden |
| 99,99 % | ca. 4,4 Minuten | ca. 52,6 Minuten |
| 99,999 % | ca. 26 Sekunden | ca. 5,3 Minuten |
Der Schritt von 99,9 % auf 99,99 % verringert die erlaubte Ausfallzeit um den Faktor zehn. Dafür braucht es Redundanz über Fehlerdomänen hinweg, automatisiertes Failover und sorgfältiges Change-Management, weshalb höhere Stufen typischerweise an dedizierte Infrastruktur und Enterprise-Verträge gebunden sind.
Sie können diese Werte selbst berechnen:
def allowed_downtime(availability_pct, period_minutes):
return period_minutes * (1 - availability_pct / 100)
MONTH = 30.44 * 24 * 60
YEAR = 365 * 24 * 60
for a in (99.0, 99.5, 99.9, 99.95, 99.99, 99.999):
print(f"{a}%: {allowed_downtime(a, MONTH):.1f} min/month, "
f"{allowed_downtime(a, YEAR) / 60:.2f} h/year")
Was ein MQTT Broker SLA üblicherweise abdeckt
Definition der Ausfallzeit
Lesen Sie, wie „nicht verfügbar" definiert ist. Bei einem Broker kann das bedeuten, dass der Endpunkt keine neuen Verbindungen annimmt, dass ein bestimmter Anteil der Verbindungsversuche fehlschlägt oder dass Nachrichten nicht zugestellt werden. Manche Verträge zählen nur Ausfälle, die länger als einige Minuten am Stück dauern, sodass kurze Aussetzer überhaupt nicht zählen.
Messmethode
Wer misst, und von wo aus? Das Monitoring des Anbieters sieht den Broker womöglich als gesund, während Ihre Geräte in einem bestimmten Netz ihn nicht erreichen. Fragen Sie, ob Sie bei der Geltendmachung von Gutschriften eigene Monitoring-Daten einreichen können.
Umfang
Prüfen Sie, welche Komponenten abgedeckt sind: Verbindungs-Endpunkte, TLS- und WebSocket-Listener, das Verwaltungsportal, APIs zur Provisionierung. Portale und APIs werden oft anders behandelt als die Datenebene oder gar nicht abgedeckt.
Service-Gutschriften
Wird das Ziel verfehlt, ist die übliche Abhilfe eine Gutschrift: ein Prozentsatz der Monatsgebühr, oft gestaffelt danach, wie stark die Verfügbarkeit gesunken ist. Gutschriften müssen meist innerhalb einer Frist beantragt werden und stehen selten im Verhältnis zu den geschäftlichen Folgen eines Ausfalls. Betrachten Sie Gutschriften als Anreiz für den Anbieter, nicht als Versicherung für Sie.
Häufige Ausschlüsse
Fast jedes SLA schließt bestimmte Ereignisse aus. Typische Ausschlüsse sind:
- Im Voraus angekündigte, geplante Wartungen.
- Probleme, die durch eigene Geräte, Netze oder Fehlkonfiguration des Kunden verursacht werden.
- Überschreitung von Planlimits, etwa Verbindungs- oder Nachrichtenquoten.
- Höhere Gewalt.
- Kostenlose, Test- oder Beta-Stufen.
- Probleme in Netzen Dritter zwischen Ihren Geräten und dem Anbieter.
Gerade kostenlose Stufen bieten selten ein vertragliches SLA. Für Entwicklung und Pilotprojekte ist das vernünftig, doch Produktionszusagen an Ihre eigenen Kunden sollten auf einem Plan mit ausdrücklichen Bedingungen beruhen.
Zusammengesetzte Verfügbarkeit: Ihr System ist eine Kette
Ihre Ende-zu-Ende-Verfügbarkeit ist nicht die Verfügbarkeit des Brokers. Eine Nachricht von einem Sensor durchläuft das Gerät, das lokale Netz, den Mobilfunk- oder Internetanbieter, den Broker, Ihr Backend und Ihre Datenbank. Sind Komponenten in Reihe geschaltet, multiplizieren sich ihre Verfügbarkeiten.
Ist zum Beispiel ein Gerätenetz zu 99,5 % verfügbar, der Broker zu 99,9 % und Ihr Backend zu 99,9 %, ergibt die Kette etwa 0,995 x 0,999 x 0,999, also rund 99,3 %. Das schwächste Glied dominiert. Viel in Broker-Neunen zu investieren, während Ihr Backend auf einem einzigen Server läuft, bringt wenig. In der Fertigung gilt zusätzlich: Sicherheitsrelevante und zeitkritische Steuerungsfunktionen gehören auf die SPS und dürfen nicht von der Verfügbarkeit eines Cloud-MQTT-Brokers abhängen; der Broker transportiert Maschinendaten, Kennzahlen und Ereignisse für MES, ERP und Dashboards. Architekturmuster finden Sie unter Hochverfügbarkeit für MQTT-Broker.
Für die vom SLA erlaubte Ausfallzeit planen
Selbst bei 99,99 % ist ein Broker gelegentlich nicht erreichbar. Bauen Sie Clients, die das tolerieren:
- Reconnect mit exponentiellem Backoff und Jitter, damit sich nicht Tausende Geräte im selben Moment neu verbinden.
- Lokal puffern auf Geräten und Edge-Gateways in der Halle und publizieren, sobald die Verbindung zurück ist.
- Persistente Sitzungen nutzen mit passender Session Expiry, damit QoS-1- und QoS-2-Nachrichten für Offline-Subscriber in die Warteschlange kommen.
- Retained Messages nutzen für Zustände, damit Dashboards direkt nach dem Reconnect den letzten bekannten Wert sehen.
- Einen Last Will setzen, damit Ihr Backend erfährt, wenn ein Gerät unerwartet weggefallen ist.
- Von außen überwachen mit einem synthetischen Client, der einen Heartbeat publiziert und empfängt.
Der Leitfaden zum MQTT-Broker-Ausfall behandelt die Incident-Seite, und die MQTT-Produktions-Checkliste macht aus diesen Punkten Aufgaben vor dem Launch.
Verfügbarkeit ist nicht dasselbe wie Dauerhaftigkeit
Ein Verfügbarkeitsziel sagt aus, ob der Broker Verbindungen annimmt und Nachrichten routet. Es sagt nichts darüber, ob jede Nachricht einen Vorfall übersteht. Fragen Sie gesondert, wie sich Sitzungen, wartende Nachrichten und Retained Messages verhalten, wenn ein Broker-Knoten neu startet oder ein Failover stattfindet, und planen Sie entsprechend der Antwort. Wenn eine verlorene Nachricht teuer wäre, halten Sie die maßgebliche Datenquelle auf dem Gerät oder in Ihrem Backend und nutzen Sie den Broker als Transportweg, nicht als Speicher. Support-Reaktionszeiten sind eine dritte, separate Zusage, die es sich genau zu lesen lohnt.
Fragen vor der Unterschrift
| Frage | Warum sie wichtig ist |
|---|---|
| Wie und von wem wird die Verfügbarkeit gemessen? | Bestimmt, was als Ausfall zählt |
| Ab welcher Mindestdauer zählt ein Ausfall? | Kurze Ausfälle sind womöglich ausgeschlossen |
| Sind geplante Wartungen ausgeschlossen, und mit welcher Vorlaufzeit werden sie angekündigt? | Geplante Ausfallzeit betrifft Geräte trotzdem |
| Welche Komponenten sind abgedeckt? | Portal und APIs können sich von Endpunkten unterscheiden |
| Wie werden Gutschriften berechnet und beantragt? | Es gelten Fristen und Obergrenzen |
| Gibt es eine Statusseite und eine Incident-Historie? | Zeigt die tatsächliche Bilanz |
| Welche Support-Reaktionszeiten gelten? | Verfügbarkeit und Support sind getrennte Zusagen |
SLAs und ConnectMQ
ConnectMQ bietet mehrere Pläne, von einer kostenlosen Serverless-Stufe auf einem geteilten Cluster über isolierte Dedicated-Cluster und BYOC in Ihrem eigenen Cloud-Account, verwaltet von ConnectMQ, bis hin zu Self Managed Enterprise. Wenn Ihr Projekt vertragliche Verfügbarkeitsbedingungen braucht, besprechen Sie diese für die Optionen Dedicated, BYOC oder Enterprise mit dem ConnectMQ-Team und prüfen Sie das Angebot anhand der obigen Fragen. Unabhängig von den Bedingungen sind es die clientseitigen Praktiken aus diesem Artikel, die Ihre Flotte gesund halten, wenn ein Broker einmal einen schlechten Tag hat.
Starten Sie mit ConnectMQ
Bauen und testen Sie Ihre Reconnect- und Pufferlogik auf einem kostenlosen Serverless-Broker unter app.connectmq.com, ganz ohne Kreditkarte, oder experimentieren Sie zuerst auf dem kostenlosen öffentlichen MQTT-Broker. Was Ihnen ein verwalteter MQTT-Broker abnimmt und wie sich Hosting-Modelle unterscheiden, lesen Sie im Leitfaden zum Cloud-MQTT-Broker.
Häufig gestellte Fragen
Wie viel Ausfallzeit erlaubt ein SLA mit 99,9 %?
Etwa 43,8 Minuten pro Monat oder rund 8,8 Stunden pro Jahr.
Garantiert ein SLA, dass meine Geräte verbunden bleiben?
Nein. Es definiert ein Verfügbarkeitsziel und die Entschädigung bei Verfehlung. Ihre Geräte brauchen weiterhin Reconnect-Logik, Pufferung und Monitoring.
Enthalten kostenlose MQTT-Broker-Pläne ein SLA?
Kostenlose Stufen enthalten in der Regel keine vertraglichen SLAs. Nutzen Sie sie für Entwicklung und Pilotprojekte und wählen Sie für Produktionszusagen einen Plan mit ausdrücklichen Bedingungen.
Ist 99,99 % immer besser als 99,9 %?
Es erlaubt zehnmal weniger Ausfallzeit, doch Ihre Ende-zu-Ende-Verfügbarkeit hängt von jeder Komponente der Kette ab. Verbessern Sie zuerst das schwächste Glied.
