Integration

So bringen Sie IoT-Sensordaten in Grafana

Bringen Sie IoT-Sensordaten in Grafana, indem Sie TagoIO als Datenquelle nutzen. Mit API-Schritten, die Sie in docs.tago.io nachschlagen können.

Thiago Lima ·
So bringen Sie IoT-Sensordaten in Grafana

Grafana läuft längst auf den Bildschirmen vieler Engineering-Teams. Es zeichnet CPU, Speicher, Request-Latenz und Queue-Tiefe, und die Teams vertrauen ihm. Wenn dann Sensordaten ins Spiel kommen, von Temperaturfühlern, Wasserzählern oder Maschinenvibration, ist der natürliche Reflex, sie in dasselbe Grafana zu packen, das ohnehin alle im Blick haben. Aber Grafana sammelt nichts von einem Gerät ein, speichert keine Zeitreihe von Messwerten und spricht keines der Protokolle, die Ihre Hardware verwendet. Es zeichnet, was eine Datenquelle ihm liefert, und nichts darüber hinaus. Die eigentliche Frage lautet also nicht “Kann Grafana IoT-Daten darstellen”, sondern “Was steht zwischen dem Gerät und Grafana und übernimmt Aufnahme, Speicherung und API”. Genau in diese Lücke passt TagoIO.

Was Grafana wirklich von Ihnen braucht

Grafana liest. Es verbindet sich mit einer Datenquelle, führt eine Abfrage aus und rendert Panels. Bei Infrastruktur ist diese Datenquelle meist Prometheus oder eine SQL-Datenbank, die etwas anderes bereits befüllt. Bei IoT-Daten müssen Sie dasselbe bereitstellen: einen Endpunkt, den Grafana abfragen kann und der zeitgestempelte Werte zurückgibt.

Grafana unterstützt das über Datenquellen-Plugins. Die Infinity-Datenquelle ist die gängige Wahl für beliebige REST-APIs. Sie kann JSON über HTTP abrufen, mit Bearer-Tokens und API-Schlüsseln umgehen und eine Antwort mit JQ oder UQL in Zeilen und Zeitreihen zerlegen. Es gibt außerdem ein JSON-API-Plugin, das Ähnliches leistet. So oder so ist der Vertrag derselbe: Geben Sie Grafana eine URL, die JSON zurückgibt, sagen Sie ihm, welche Felder Zeitstempel und Wert sind, und es zeichnet den Rest.

Was keines dieser Plugins tut, ist mit Ihren Sensoren zu sprechen. Sie setzen voraus, dass die Daten bereits irgendwo existieren und eine HTTP-Tür nach außen haben. Genau diese Annahme ist die eigentliche Arbeit, und das ist der Teil, den Grafana abgibt.

Der Teil vor Grafana: Aufnahme und Speicherung

Ein Sensor im Feld gibt nicht von sich aus sauberes JSON über HTTPS aus. Er spricht LoRaWAN über einen Network Server, oder NB-IoT, oder rohes MQTT, oder er sendet einen herstellerspezifischen Payload, der dekodiert werden muss. Bevor daraus eine Grafik wird, müssen drei Dinge passieren:

  • Der Messwert muss empfangen werden, was bedeutet, das Geräteprotokoll und das Netz, über das es läuft, zu handhaben.
  • Der rohe Payload muss in benannte Variablen mit Einheiten und Zeitstempeln zerlegt werden.
  • Die zerlegten Werte müssen als Zeitreihe gespeichert werden, die Sie später abfragen können, nicht nur als letzter Messwert.

Das ist die Arbeit, die TagoIO übernimmt. Geräte verbinden sich über HTTP oder MQTT, wobei MQTT auf Port 1883 oder 8883 über SSL verfügbar ist. TagoIO bietet Geräteintegrationen für über 500 Modelle und Netze, sodass die Protokollverarbeitung erledigt ist, bevor Sie irgendetwas schreiben. Ein Payload-Parser verwandelt die rohen Bytes in Variablen wie temperature oder fuel_level. Diese landen in der Zeitreihen-Speicherung, wobei jeder Datensatz ein time, einen value, einen variable-Namen und oft eine unit trägt. Die genaue Einrichtung von Connector und Parser steht in docs.tago.io, und die Schritte unterscheiden sich je nach Gerät, folgen Sie also der Dokumentation für Ihre konkrete Hardware statt einem generischen Rezept.

Der Punkt ist: Wenn Grafana nach Daten fragt, existieren die Daten bereits, sind sauber und haben eine API davor.

TagoIO-Daten so bereitstellen, dass Grafana sie lesen kann

TagoIO hat eine vollständige REST-API, und das Lesen von Gerätedaten daraus ist ein GET-Request. Der Endpunkt ist die regionale Daten-URL:

GET https://api.<region>.tago.io/data

Die Authentifizierung erfolgt über ein Device Token, das im Authorization-Header übergeben wird. Laut docs.tago.io sieht der Request zum Abrufen einer einzelnen Variable so aus:

https://api.<region>.tago.io/data?variable=temperature&qty=99

Sie können nach Zeitfenster filtern mit start_date und end_date, die ISO-Strings oder relative Ausdrücke wie 1 day akzeptieren. Sie können mit query=last_item nur nach dem letzten Messwert fragen. Und Sie können mehrere Variablen auf einmal anfordern, über die Array-Syntax variable[]=temperature&variable[]=pressure.

Die Antwort ist JSON mit einem result-Array, in dem jeder Eintrag die Felder trägt, die für Grafana zählen:

{
  "status": true,
  "result": [
    {
      "id": "547e353d7dbf3af122c0257d",
      "time": "2014-12-02T21:55:09.301Z",
      "unit": "%",
      "value": 32,
      "variable": "fuel_level"
    }
  ]
}

Diese Struktur lässt sich sauber auf eine Infinity- oder JSON-API-Abfrage abbilden. Die Wurzel ist result, time ist Ihre Zeitstempelspalte, value ist die numerische Spalte, und variable erlaubt es Ihnen, Serien aufzuteilen oder zu filtern. Richten Sie die Grafana-Datenquelle auf die TagoIO-Daten-URL, setzen Sie den Authorization-Header mit Ihrem Device Token, legen Sie die Wurzel auf result fest und ordnen Sie die Spalten zu. Ab da ist es ein ganz normales Grafana-Panel.

Ein paar ehrliche Hinweise, die Sie gegen die Dokumentation prüfen sollten. TagoIO wendet Rate Limits an, ein Dashboard also, das sich über viele Panels alle paar Sekunden aktualisiert, kann an sie stoßen. Der Standardwert für qty ist klein, setzen Sie ihn also explizit, wenn Sie einen echten Zeitbereich wollen. Und Tokens sind im Geltungsbereich begrenzt, überlegen Sie also, welches Token eine gemeinsam genutzte Grafana-Instanz halten sollte, bevor Sie es in eine Datenquelle einfügen.

Wann Sie Grafana nicht über TagoIO brauchen

Diesen Weg lohnt es sich nur zu gehen, wenn das zweite Werkzeug sich verdient. TagoIO hat eigene Dashboards und Widgets. Wenn Sie Liniendiagramme, Anzeigen, Karten und Tabellen über Gerätedaten brauchen, decken die eingebauten Dashboards das bereits ab, und Grafana hinzuzunehmen bedeutet, ein weiteres System zu betreiben und zu warten, einen weiteren Satz an Zugangsdaten zu verwalten und zwei Definitionen derselben Grafik synchron zu halten. Das sind mehr bewegliche Teile für ein Ergebnis, das Sie schon haben.

Grafana obendrauf ergibt in bestimmten Fällen Sinn. Sie standardisieren teamübergreifend auf Grafana und wollen, dass IoT-Daten neben Infrastruktur-Metriken liegen, damit alle an einer Stelle nachschauen. Sie brauchen ein Grafana-spezifisches Panel, eine Alarmregel oder ein Plugin, das TagoIO nicht bietet. Sie führen IoT-Messwerte mit Nicht-IoT-Quellen in einer einzigen Grafana-Ansicht zusammen. In diesen Fällen zahlt sich das zusätzliche Werkzeug aus. Trifft keiner davon zu, bleiben Sie bei TagoIO und sparen Sie sich die Integration.

Wo TagoIO hineinpasst

Grafana ist die Darstellungsschicht, und darin ist es gut. Was es nicht leisten kann, ist alles, was passiert, bevor eine Abfrage sauberes JSON zurückgibt: den Empfang vom Gerät, das Dekodieren des Payloads und das Vorhalten einer abfragbaren Zeitreihe. TagoIO erledigt diese Arbeit und stellt das Ergebnis dann über eine dokumentierte REST-API bereit, also genau die Art von Quelle, die Grafana-Plugins lesen sollen. Sie behalten Grafana als Glasfront und lassen TagoIO der Teil des Stacks sein, der Hardware in Daten verwandelt.

Nächste Schritte