Alertes Grafana sur les données de capteurs IoT : seuils, capteurs muets et notifications

Les alertes Grafana sur les données de capteurs IoT transforment un tableau de bord que quelqu'un doit surveiller en un système qui vous prévient quand quelque chose ne va pas. Dans ce tutoriel, vous allez créer des règles d'alerte sur des mesures de capteurs MQTT stockées dans InfluxDB : un seuil de température par appareil, une règle qui repère les capteurs qui cessent d'émettre et le routage des notifications, avant de les comparer aux règles de seuil intégrées au portail ConnectMQ.

Prérequis

Ce guide s'appuie sur la stack de notre tutoriel sur la stack TIG avec Docker Compose, dans laquelle Telegraf s'abonne à des topics MQTT sur broker.connectmq.com, le serveur MQTT public gratuit réservé aux tests, et écrit dans InfluxDB 2. Le modèle de données est le suivant :

Toute source de données InfluxDB dans Grafana 10 ou 11 fonctionne de la même façon. Si vos données proviennent plutôt d'une passerelle Python, comme décrit dans stocker des données MQTT dans InfluxDB, seul le nom de la measurement change dans les requêtes.

Comment l'alerting Grafana évalue les règles

L'alerting Grafana s'exécute sur le serveur Grafana, pas dans votre navigateur, et fonctionne indépendamment des tableaux de bord. Chaque règle suit le même pipeline :

1. Requête. Récupérer des données récentes depuis la source de données, par exemple les dix dernières minutes de températures.
2. Expressions. Réduire chaque série à un seul nombre, comme la dernière valeur ou la moyenne, et le comparer à un seuil.
3. Évaluation. La règle s'exécute à un intervalle fixe défini par son groupe d'évaluation.
4. Période d'attente (pending period). Une condition doit rester vraie pendant cette durée avant que l'alerte ne se déclenche, ce qui filtre les mesures bruitées isolées.
5. Notification. Les alertes déclenchées et résolues sont acheminées par des politiques de notification vers des contact points comme l'e-mail, Slack, Microsoft Teams, Telegram ou un webhook.

La propriété la plus importante pour l'IoT est que les règles sont multidimensionnelles. Si la requête renvoie une série par appareil, Grafana crée une instance d'alerte par appareil. Une seule règle couvre donc toute votre flotte, et la notification vous indique exactement quel capteur est concerné.

Règle 1 : seuil de température par appareil

Dans Grafana, ouvrez Alerting, puis Alert rules, puis New alert rule.

Nom : High temperature

Requête A (source de données InfluxDB, 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)

C'est l'appel group qui rend la règle multidimensionnelle : chaque appareil devient sa propre série et sa propre instance d'alerte. La moyenne sur des fenêtres d'une minute lisse le bruit de mesure avant l'application du seuil.

Expression B : Reduce. Entrée A, fonction Last, mode « Drop non-numeric values ». Chaque série est ainsi ramenée à sa dernière moyenne sur une minute.

Expression C : Threshold. Entrée B, is above 30. Définissez C comme condition d'alerte.

Dossier et labels. Placez la règle dans un dossier comme IoT et ajoutez un label severity=warning. Les labels piloteront ensuite le routage des notifications.

Comportement d'évaluation. Créez un groupe d'évaluation nommé sensors-1m avec un intervalle d'une minute, et réglez la période d'attente sur 5 minutes. L'alerte ne se déclenche alors que lorsqu'un appareil a dépassé une moyenne de 30 degrés pendant cinq évaluations consécutives.

Annotations. Ajoutez un résumé qui nomme l'appareil et la valeur :

{{ $labels.device }} on {{ $labels.line }} is at {{ printf "%.1f" $values.B.Value }} °C

Cliquez sur Save rule and exit. En moins d'une minute, la liste des règles affiche une instance par appareil à l'état Normal.

Règle 2 : détecter les capteurs qui cessent d'émettre

Un capteur qui tombe en panne n'envoie pas une valeur élevée : il n'envoie rien. Les règles de seuil ne peuvent pas le détecter à elles seules, et en pratique, les capteurs muets comptent parmi les pannes IoT les plus fréquentes. Deux approches complémentaires existent.

Option A : configurer la gestion de l'absence de données

Dans chaque règle, la section d'évaluation comporte un paramètre qui définit ce qui se passe lorsque la requête ne renvoie aucune donnée. Les options sont No Data, Alerting, Normal et Keep Last State. Pour une règle portant sur un seul appareil, choisir Alerting suffit. Pour une règle multidimensionnelle, ce n'est pas le cas, car la requête renvoie toujours des données pour les appareils sains : un seul appareil muet ne déclenche donc aucun état d'absence de données.

Option B : alerter sur l'âge des données par appareil

Calculez le nombre de secondes écoulées depuis la dernière mesure de chaque appareil et déclenchez une alerte lorsqu'il devient trop grand :

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 }))

Utilisez Reduce Last comme expression B et Threshold « is above 120 » comme expression C, avec une période d'attente de 2 minutes. Choisissez le seuil en fonction de l'intervalle de publication de l'appareil : environ quatre fois l'intervalle est un bon point de départ, si bien qu'un capteur qui publie toutes les 30 secondes est signalé après deux minutes de silence. Un appareil silencieux depuis plus que la plage d'une heure disparaît complètement de la requête : réglez donc aussi le comportement en absence de données de cette règle sur Alerting, ce qui couvre le cas où toute la flotte devient muette.

Règle 3 : router les notifications

Créez un contact point dans Alerting, puis Contact points. Slack, Microsoft Teams, Telegram et les webhooks génériques n'ont besoin que d'une URL ou d'un token. L'e-mail nécessite des paramètres SMTP sur le serveur Grafana ; avec Docker, ajoutez-les sous forme de variables d'environnement :

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

Ouvrez ensuite Notification policies et ajoutez une politique enfant qui correspond à severity=warning et envoie vers votre contact point. Regroupez les notifications par alertname et line pour que dix capteurs en surchauffe sur la même ligne produisent un seul message au lieu de dix. Utilisez des mute timings pour les fenêtres de maintenance planifiées pendant lesquelles les capteurs sont censés être hors ligne.

Tester l'alerte de bout en bout

N'attendez pas une vraie panne pour savoir si les alertes fonctionnent. Publiez des mesures élevées pour un appareil avec un identifiant de test unique :

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

En une minute environ, l'instance sensor-test passe à l'état Pending. Après la période d'attente de cinq minutes, elle passe à Firing et la notification arrive. Arrêtez la boucle et deux autres événements doivent se produire : l'alerte de température élevée se résout, puis après deux minutes de silence, la règle des capteurs muets se déclenche pour sensor-test. Ce seul test valide toute la chaîne, du broker à la notification. Le simulateur d'appareils MQTT est utile pour des tests plus longs, puisque ses appareils défaillants produisent des pics occasionnels.

Checklist de réglage

1. Lissez les signaux bruités avec aggregateWindow avant d'appliquer les seuils.
2. Utilisez une période d'attente de plusieurs intervalles d'évaluation pour ignorer les pics isolés.
3. Regroupez uniquement par des tags stables, pour que chaque instance d'alerte corresponde à un appareil réel.
4. Traitez explicitement le silence avec une règle sur l'âge des données et des paramètres d'absence de données adaptés.
5. Regroupez les notifications par ligne ou par site pour éviter les avalanches d'alertes.
6. Exportez les règles finalisées en YAML depuis le menu de la règle et conservez-les sous contrôle de version, afin qu'un Grafana reconstruit puisse les provisionner à partir de fichiers.

Alerting Grafana ou règles d'alerte de seuil ConnectMQ

ConnectMQ propose aussi des règles d'alerte de seuil dans son portail, les alertes déclenchées étant enregistrées dans un journal des alertes. Les deux approches se situent à des endroits différents du pipeline et se complètent.

Une combinaison pratique consiste à utiliser les règles de seuil du portail pendant la mise en service des appareils, quand aucune base de données n'existe encore, puis à ajouter des règles Grafana dès que l'historique et les notifications d'astreinte deviennent importants. Les deux lisent les mêmes topics ; aucune ne nécessite de modifier les appareils.

Côté ingestion, le guide Telegraf MQTT consumer détaille la configuration de l'input, et le guide des bibliothèques clientes MQTT vous aide lorsque vous écrivez le code des appareils. La documentation d'alerting de Grafana couvre toutes les options des règles.

Démarrez avec ConnectMQ

Vous pouvez construire et tester ces alertes dès aujourd'hui avec le serveur MQTT public gratuit et des données simulées. Pour la production, faites tourner vos appareils sur un broker MQTT managé avec TLS et des identifiants privés. ConnectMQ vous fournit ce broker ainsi qu'un portail avec explorateur de topics en direct, tableau de bord et règles d'alerte de seuil. Créez un broker Serverless gratuit sur app.connectmq.com sans carte bancaire et connectez Telegraf avec les identifiants générés.

Questions fréquentes

Une seule règle d'alerte Grafana peut-elle couvrir tous mes capteurs IoT ?

Oui. Regroupez la requête par un tag d'appareil et Grafana crée une instance d'alerte distincte pour chaque appareil, le tout à partir d'une seule règle.

Comment déclencher une alerte quand un capteur cesse d'envoyer des données ?

Calculez dans la requête l'âge de la dernière mesure de chaque appareil et alertez lorsqu'il dépasse quelques intervalles de publication. La gestion de l'absence de données ne suffit pas, à elle seule, à détecter un appareil muet dans une règle multi-appareils.

Quelle période d'attente utiliser pour les alertes de capteurs ?

Commencez par trois à cinq intervalles d'évaluation. Des périodes plus courtes réagissent plus vite mais génèrent davantage de fausses alertes dues aux mesures bruitées.

Ai-je besoin de Grafana si mon broker propose déjà des alertes de seuil ?

Pas pour de simples seuils. Grafana prend tout son intérêt lorsque vous avez besoin de tendances, de fenêtres temporelles, de contrôles d'âge des données et d'un routage vers les canaux d'astreinte.