Grafana-Alarme für IoT-Sensordaten verwandeln ein Dashboard, das jemand beobachten muss, in ein System, das Ihnen meldet, wenn etwas nicht stimmt. In diesem Tutorial erstellen Sie Alarmregeln auf MQTT-Sensormesswerten, die in InfluxDB gespeichert sind: einen Temperaturschwellenwert pro Gerät, eine Regel, die Sensoren erkennt, die keine Daten mehr senden, und die Weiterleitung von Benachrichtigungen, gefolgt von einem Vergleich mit den Schwellenwertregeln, die im ConnectMQ-Portal integriert sind.
Voraussetzungen
Dieser Leitfaden baut auf dem Stack aus unserem Tutorial zum TIG-Stack mit Docker Compose auf, in dem Telegraf MQTT-Topics auf broker.connectmq.com abonniert und in InfluxDB 2 schreibt. Das Datenmodell lautet:
| Element | Wert |
|---|---|
| Bucket | sensors |
| Measurement | sensor |
| Tags | device, line |
| Fields | temperature, humidity |
| Quell-Topics | connectmq/demo/<run-id>/<line>/<device>/telemetry |
Jede InfluxDB-Datenquelle in Grafana 10 oder 11 funktioniert auf dieselbe Weise. Stammen Ihre Daten stattdessen aus einer Python-Bridge, wie unter MQTT-Daten in InfluxDB speichern beschrieben, ändert sich nur der Measurement-Name in den Abfragen.
Wie Grafana Alerting Regeln auswertet
Grafana Alerting läuft auf dem Grafana-Server, nicht in Ihrem Browser, und arbeitet unabhängig von Dashboards. Jede Regel durchläuft dieselbe Pipeline:
- Abfrage. Aktuelle Daten aus der Datenquelle holen, zum Beispiel die Temperaturen der letzten zehn Minuten.
- Expressions. Jede Serie auf eine einzige Zahl reduzieren, etwa den letzten oder den Mittelwert, und mit einem Schwellenwert vergleichen.
- Auswertung. Die Regel läuft in einem festen Intervall, das ihre Evaluation Group festlegt.
- Pending-Periode. Eine Bedingung muss so lange wahr bleiben, bevor der Alarm auslöst, was einzelne verrauschte Messwerte herausfiltert.
- Benachrichtigung. Auslösende und behobene Alarme werden über Notification Policies an Contact Points wie E-Mail, Slack, Microsoft Teams, Telegram oder einen Webhook weitergeleitet.
Die wichtigste Eigenschaft für IoT ist, dass Regeln mehrdimensional sind. Liefert die Abfrage eine Serie pro Gerät, erzeugt Grafana eine Alarminstanz pro Gerät. Eine einzige Regel deckt also Ihre gesamte Flotte ab, und die Benachrichtigung nennt Ihnen genau den betroffenen Sensor.
Regel 1: Temperaturschwellenwert pro Gerät
Öffnen Sie in Grafana Alerting, dann Alert rules, dann New alert rule.
Name: High temperature
Abfrage A (InfluxDB-Datenquelle, Flux):
from(bucket: "sensors")
|> range(start: -10m)
|> filter(fn: (r) => r._measurement == "sensor" and r._field == "temperature")
|> group(columns: ["device", "line"])
|> aggregateWindow(every: 1m, fn: mean, createEmpty: false)
Der group-Aufruf macht die Regel mehrdimensional: Jedes Gerät wird zu einer eigenen Serie und einer eigenen Alarminstanz. Die Mittelung über Ein-Minuten-Fenster glättet Messrauschen, bevor der Schwellenwert angewendet wird.
Expression B: Reduce. Input A, Funktion Last, Modus "Drop non-numeric values". Damit wird jede Serie zu ihrem jüngsten Ein-Minuten-Mittelwert.
Expression C: Threshold. Input B, is above 30. Legen Sie C als Alarmbedingung fest.
Ordner und Labels. Legen Sie die Regel in einen Ordner wie IoT und fügen Sie ein Label severity=warning hinzu. Labels steuern später die Weiterleitung der Benachrichtigungen.
Auswertungsverhalten. Erstellen Sie eine Evaluation Group namens sensors-1m mit einem Intervall von 1 Minute und setzen Sie die Pending-Periode auf 5 Minuten. Der Alarm löst dann nur aus, wenn ein Gerät fünf aufeinanderfolgende Auswertungen lang im Mittel über 30 Grad lag.
Annotations. Fügen Sie eine Zusammenfassung hinzu, die Gerät und Wert nennt:
{{ $labels.device }} on {{ $labels.line }} is at {{ printf "%.1f" $values.B.Value }} °C
Klicken Sie auf Save rule and exit. Innerhalb einer Minute zeigt die Regelliste eine Instanz pro Gerät im Zustand Normal.
Regel 2: Sensoren erkennen, die keine Daten mehr senden
Ein ausgefallener Sensor sendet keinen hohen Wert; er sendet gar nichts. Schwellenwertregeln allein können das nicht erkennen, und in der Praxis gehören stille Sensoren zu den häufigsten IoT-Ausfällen. Es gibt zwei sich ergänzende Ansätze.
Option A: No-Data-Behandlung konfigurieren
In jeder Regel enthält der Auswertungsbereich eine Einstellung dafür, was passiert, wenn die Abfrage keine Daten liefert. Die Optionen sind No Data, Alerting, Normal und Keep Last State. Für eine Regel mit einem einzelnen Gerät genügt es, sie auf Alerting zu setzen. Für eine mehrdimensionale Regel nicht, denn die Abfrage liefert für die gesunden Geräte weiterhin Daten, sodass ein einzelnes stilles Gerät überhaupt keinen No-Data-Zustand auslöst.
Option B: Alarm auf das Datenalter pro Gerät
Berechnen Sie, wie viele Sekunden seit dem letzten Messwert jedes Geräts vergangen sind, und alarmieren Sie, wenn dieser Wert zu groß wird:
from(bucket: "sensors")
|> range(start: -1h)
|> filter(fn: (r) => r._measurement == "sensor" and r._field == "temperature")
|> group(columns: ["device", "line"])
|> last()
|> map(fn: (r) => ({ r with _value: float(v: uint(v: now()) - uint(v: r._time)) / 1000000000.0 }))
Verwenden Sie Reduce Last als Expression B und Threshold "is above 120" als Expression C, mit einer Pending-Periode von 2 Minuten. Wählen Sie den Schwellenwert anhand des Publish-Intervalls des Geräts: Etwa das Vierfache des Intervalls ist ein vernünftiger Start, sodass ein Sensor, der alle 30 Sekunden veröffentlicht, nach zwei stillen Minuten markiert wird. Ein Gerät, das länger als den einstündigen Abfragezeitraum still ist, verschwindet vollständig aus der Abfrage; setzen Sie daher auch das No-Data-Verhalten dieser Regel auf Alerting, was den Fall abdeckt, dass die gesamte Flotte verstummt.
Regel 3: Benachrichtigungen weiterleiten
Erstellen Sie einen Contact Point unter Alerting, dann Contact points. Slack, Microsoft Teams, Telegram und generische Webhooks benötigen nur eine URL oder ein Token. E-Mail erfordert SMTP-Einstellungen auf dem Grafana-Server; mit Docker fügen Sie diese als Umgebungsvariablen hinzu:
services:
grafana:
environment:
GF_SMTP_ENABLED: "true"
GF_SMTP_HOST: smtp.example.com:587
GF_SMTP_USER: alerts@example.com
GF_SMTP_PASSWORD: ${SMTP_PASSWORD}
GF_SMTP_FROM_ADDRESS: alerts@example.com
GF_SMTP_FROM_NAME: IoT Alerts
Öffnen Sie dann Notification policies und fügen Sie eine untergeordnete Policy hinzu, die auf severity=warning passt und an Ihren Contact Point sendet. Gruppieren Sie Benachrichtigungen nach alertname und line, damit zehn überhitzte Sensoren auf derselben Linie eine Nachricht statt zehn erzeugen. Verwenden Sie Mute Timings für geplante Wartungsfenster, in denen Sensoren erwartungsgemäß offline gehen. Stammen die Daten aus einem Unified Namespace (UNS) nach ISA-95, etwa acme/werk-muenchen/montage/linie-1/zelle-3/temperatur, übernimmt Telegraf Werk, Bereich und Linie direkt als Tags. Benachrichtigungen lassen sich dann gezielt an die zuständige Instandhaltung je Halle oder Linie leiten.
Den Alarm Ende-zu-Ende testen
Warten Sie nicht auf einen echten Ausfall, um herauszufinden, ob Alarme funktionieren. Veröffentlichen Sie erhöhte Messwerte für ein Gerät mit einer eindeutigen Test-ID:
ID=a1b2c3
for i in $(seq 1 60); do
mosquitto_pub -h broker.connectmq.com -p 1883 -i "alerttest-$ID" \
-t "connectmq/demo/$ID/line1/sensor-test/telemetry" \
-m "{\"device\":\"sensor-test\",\"ts\":$(date +%s%3N),\"temperature\":35.5,\"humidity\":40.0}"
sleep 10
done
Innerhalb von etwa einer Minute wechselt die Instanz sensor-test in den Zustand Pending. Nach der fünfminütigen Pending-Periode wechselt sie zu Firing, und die Benachrichtigung trifft ein. Stoppen Sie die Schleife, dann sollten zwei weitere Dinge passieren: Der Hochtemperatur-Alarm wird behoben, und nach zwei stillen Minuten löst die Regel für inaktive Sensoren für sensor-test aus. Dieser eine Test beweist die gesamte Kette vom Broker bis zur Benachrichtigung. Der MQTT-Gerätesimulator ist für längere Tests nützlich, da seine fehlerhaften Geräte gelegentlich Spitzen erzeugen.
Checkliste zur Feinabstimmung
- Glätten Sie verrauschte Signale mit
aggregateWindow, bevor Sie Schwellenwerte anwenden. - Verwenden Sie eine Pending-Periode von mehreren Auswertungsintervallen, um einmalige Spitzen zu ignorieren.
- Gruppieren Sie nur nach stabilen Tags, damit jede Alarminstanz einem echten Gerät entspricht.
- Behandeln Sie Stille explizit mit einer Datenalter-Regel und sinnvollen No-Data-Einstellungen.
- Gruppieren Sie Benachrichtigungen nach Linie oder Standort, um Alarmstürme zu vermeiden.
- Exportieren Sie fertige Regeln über das Menü der Regel als YAML und legen Sie sie in die Versionsverwaltung, damit ein neu aufgesetztes Grafana sie aus Dateien provisionieren kann.
Grafana Alerting im Vergleich zu den Schwellenwert-Alarmregeln von ConnectMQ
ConnectMQ bietet in seinem Portal ebenfalls Schwellenwert-Alarmregeln, wobei ausgelöste Alarme in einem Alarmprotokoll erfasst werden. Die beiden Ansätze sitzen an unterschiedlichen Stellen der Pipeline und ergänzen einander.
| Aspekt | Grafana Alerting | Schwellenwert-Alarmregeln von ConnectMQ |
|---|---|---|
| Wo es läuft | Grafana-Server, auf gespeicherten Daten | Broker-Portal, auf eingehenden MQTT-Werten |
| Benötigt eine Datenbank | Ja, etwa InfluxDB | Nein |
| Logik über Zeitfenster | Aggregationen, Pending-Perioden, Datenalter | Einfache Schwellenwerte auf Werte |
| Weiterleitung von Benachrichtigungen | Contact Points und Policies | Alarmprotokoll im Portal |
| Einrichtungsaufwand | Höher, Teil eines TIG-Stacks | Gering, im Portal konfiguriert |
| Am besten geeignet für | Trends, flottenweite Regeln, Bereitschaftsweiterleitung | Schnelle Übersicht bei Inbetriebnahme und kleinen Deployments |
Eine praktische Kombination ist, die Schwellenwertregeln des Portals zu nutzen, während Geräte in Betrieb genommen werden und noch keine Datenbank existiert, und Grafana-Regeln zu ergänzen, sobald Historie und Bereitschaftsbenachrichtigungen wichtig werden. Beide lesen dieselben Topics; keiner der Ansätze erfordert Änderungen an den Geräten.
Für die Ingestion-Seite erklärt der Leitfaden zum Telegraf MQTT Consumer die Input-Konfiguration im Detail, und der Leitfaden zu MQTT-Client-Bibliotheken hilft beim Schreiben von Gerätecode. Grafanas eigene Alerting-Dokumentation behandelt jede Regeloption.
Starten Sie mit ConnectMQ
Sie können diese Alarme noch heute mit dem öffentlichen MQTT-Broker und simulierten Daten bauen und testen; er ist für Tests und Prototypen gedacht, nicht für Produktionsdaten. Für die Produktion betreiben Sie Ihre Geräte auf einem verwalteten MQTT-Broker mit TLS und privaten Zugangsdaten. ConnectMQ bietet Ihnen diesen Broker plus ein Portal mit Live-Topic-Explorer, Dashboard und Schwellenwert-Alarmregeln. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker ohne Kreditkarte und verbinden Sie Telegraf mit den generierten Zugangsdaten.
Häufig gestellte Fragen
Kann eine einzige Grafana-Alarmregel alle meine IoT-Sensoren abdecken?
Ja. Gruppieren Sie die Abfrage nach einem Geräte-Tag, und Grafana erzeugt aus einer einzigen Regel eine separate Alarminstanz für jedes Gerät.
Wie alarmiere ich, wenn ein Sensor keine Daten mehr sendet?
Berechnen Sie in der Abfrage das Alter des letzten Messwerts jedes Geräts und alarmieren Sie, wenn es einige Publish-Intervalle überschreitet. Die No-Data-Behandlung allein erkennt ein einzelnes stilles Gerät in einer Regel für mehrere Geräte nicht.
Welche Pending-Periode sollte ich für Sensoralarme verwenden?
Beginnen Sie mit drei bis fünf Auswertungsintervallen. Kürzere Perioden reagieren schneller, erzeugen aber mehr Fehlalarme durch verrauschte Messwerte.
Brauche ich Grafana, wenn mein Broker bereits Schwellenwert-Alarme hat?
Für einfache Schwellenwerte nicht. Grafana wird wertvoll, wenn Sie Trends, Zeitfenster, Datenalter-Prüfungen und die Weiterleitung an Bereitschaftskanäle benötigen.
