Comment faire entrer les données de capteurs IoT dans Grafana

Grafana est déjà à l’écran dans bon nombre de salles d’ingénierie. Il trace l’usage CPU, la mémoire, la latence des requêtes et la profondeur des files d’attente, et les équipes lui font confiance. Alors quand les données de capteurs commencent à apparaître, qu’il s’agisse de sondes de température, de compteurs d’eau ou de vibrations de machines, l’instinct naturel est de les afficher dans le même Grafana que tout le monde surveille déjà. Mais Grafana ne collecte rien depuis un appareil, ne stocke aucune série temporelle de relevés, et ne parle pas les protocoles utilisés par votre matériel. Il dessine ce qu’une source de données lui transmet, et rien de plus. La vraie question n’est donc pas “Grafana peut-il tracer des données IoT”, mais “qu’est-ce qui se trouve entre l’appareil et Grafana pour faire l’ingestion, le stockage et l’API”, et c’est dans cet écart que TagoIO s’insère.

Ce dont Grafana a réellement besoin de votre part

Grafana lit. Il se connecte à une source de données, exécute une requête, et affiche des panneaux. Pour l’infrastructure, cette source de données est généralement Prometheus ou une base SQL que quelque chose d’autre remplit déjà. Pour les données IoT, vous devez fournir la même chose : un endpoint que Grafana peut interroger et qui renvoie des valeurs horodatées.

Grafana gère cela via des plugins de source de données. La source de données Infinity est le choix courant pour les API REST arbitraires. Elle peut récupérer du JSON via HTTP, gérer les tokens Bearer et les clés API, et analyser une réponse en lignes et en séries temporelles avec JQ ou UQL. Il existe aussi un plugin JSON API qui fait un travail similaire. Dans les deux cas, le contrat est identique : donnez à Grafana une URL qui renvoie du JSON, indiquez-lui quels champs sont l’horodatage et la valeur, et il trace le reste.

Ce qu’aucun de ces plugins ne fait, c’est parler à vos capteurs. Ils partent du principe que les données existent déjà quelque part, derrière une porte HTTP. Cette hypothèse, c’est tout le travail, et c’est précisément la partie que Grafana délègue.

La partie avant Grafana : ingestion et stockage

Un capteur sur le terrain n’émet pas seul du JSON propre via HTTPS. Il parle LoRaWAN à travers un serveur réseau, ou NB-IoT, ou du MQTT brut, ou bien il envoie un payload propre à un fournisseur qui doit être décodé. Avant que tout cela ne devienne un graphique, trois choses doivent se produire :

• Le relevé doit être reçu, ce qui implique de gérer le protocole de l’appareil et le réseau qu’il emprunte.
• Le payload brut doit être analysé en variables nommées, avec unités et horodatages.
• Les valeurs analysées doivent être stockées sous forme de série temporelle interrogeable plus tard, et pas seulement le dernier relevé.

C’est le travail que fait TagoIO. Les appareils se connectent via HTTP ou MQTT, MQTT étant disponible sur le port 1883 ou 8883 en SSL. TagoIO propose des intégrations d’appareils pour plus de 500 modèles et réseaux, si bien que la gestion du protocole est réglée avant même que vous n’écriviez quoi que ce soit. Un payload parser transforme les octets bruts en variables comme temperature ou fuel_level. Celles-ci sont enregistrées dans un stockage en série temporelle, chaque enregistrement portant un time, une value, un nom de variable, et souvent une unit. La configuration exacte du connecteur et du parser se trouve sur docs.tago.io, et les étapes varient selon l’appareil, alors suivez la documentation correspondant à votre matériel précis plutôt qu’une recette générique.

L’idée, c’est qu’au moment où Grafana demande les données, celles-ci existent, sont propres, et disposent d’une API en façade.

Exposer les données TagoIO pour que Grafana puisse les lire

TagoIO dispose d’une API REST complète, et lire les données d’un appareil revient à faire une requête GET. L’endpoint est l’URL de données régionale :

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

L’authentification se fait par un Device Token passé dans l’en-tête Authorization. D’après docs.tago.io, la requête pour récupérer une seule variable ressemble à ceci :

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

Vous pouvez filtrer par fenêtre temporelle avec start_date et end_date, qui acceptent des chaînes ISO ou des expressions relatives comme 1 day. Vous pouvez demander uniquement le dernier relevé avec query=last_item. Vous pouvez requêter plusieurs variables à la fois en utilisant la syntaxe de tableau, variable[]=temperature&variable[]=pressure.

La réponse est un JSON contenant un tableau result, où chaque entrée porte les champs qui intéressent Grafana :

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

Cette structure se mappe proprement sur une requête Infinity ou JSON API. La racine est result, time est votre colonne d’horodatage, value est la colonne numérique, et variable permet de séparer ou de filtrer les séries. Pointez la source de données Grafana vers l’URL de données TagoIO, renseignez l’en-tête Authorization avec votre Device Token, définissez la racine sur result, et mappez les colonnes. À partir de là, c’est un panneau Grafana classique.

Quelques mises en garde honnêtes à vérifier dans la documentation. TagoIO applique des limites de débit, donc un dashboard qui se rafraîchit toutes les quelques secondes sur de nombreux panneaux peut les atteindre. La valeur qty par défaut est faible, alors définissez-la explicitement quand vous voulez une vraie plage temporelle. Et les tokens sont limités en portée, réfléchissez donc au token qu’une instance Grafana partagée doit détenir avant de le coller dans une source de données.

Quand vous n’avez pas besoin de Grafana au-dessus de TagoIO

Ce chemin ne vaut la peine que lorsqu’il justifie le second outil. TagoIO possède ses propres dashboards et widgets. Si votre besoin se résume à des courbes, des jauges, des cartes et des tableaux sur des données d’appareils, les dashboards intégrés couvrent déjà tout cela, et ajouter Grafana signifie faire tourner et maintenir un autre système, gérer un autre jeu d’identifiants, et synchroniser deux définitions du même graphique. C’est davantage de pièces mobiles pour un résultat que vous avez déjà.

Mettre Grafana par-dessus a du sens dans des cas précis. Vous standardisez sur Grafana entre les équipes et vous voulez que les données IoT vivent à côté des métriques d’infrastructure pour que chacun regarde au même endroit. Vous avez besoin d’un panneau, d’une règle d’alerte ou d’un plugin propre à Grafana que TagoIO ne propose pas. Vous fusionnez des relevés IoT avec des sources non IoT dans une même vue Grafana. Dans ces cas-là, l’outil supplémentaire se rentabilise. Si aucun de ces cas ne s’applique, restez dans TagoIO et passez l’intégration.

Où TagoIO s’insère

Grafana est la couche d’affichage, et il excelle à être la couche d’affichage. Le travail qu’il ne peut pas faire, c’est tout ce qui se passe avant qu’une requête ne renvoie du JSON propre : recevoir depuis l’appareil, décoder le payload, et entretenir une série temporelle interrogeable. TagoIO fait ce travail, puis expose le résultat via une API REST documentée, soit exactement le type de source que les plugins Grafana sont conçus pour lire. Vous gardez Grafana comme vitrine et vous laissez TagoIO être la partie de la stack qui transforme le matériel en données.

Étapes suivantes

• Découvrez comment récupérer les données d’un appareil via l’API : Getting Data sur docs.tago.io
• Passez en revue les types de tokens et leur portée : Device Token sur docs.tago.io
• Vérifiez les détails de connexion MQTT si vous préférez l’ingestion en flux : MQTT Overview sur docs.tago.io
• Créez un compte et connectez un appareil : tago.io