Alertas de Grafana para datos de sensores IoT: umbrales, sensores inactivos y notificaciones

Las alertas de Grafana para datos de sensores IoT convierten un dashboard que alguien tiene que vigilar en un sistema que te avisa cuando algo va mal. En este tutorial crearás reglas de alerta sobre lecturas de sensores MQTT almacenadas en InfluxDB: un umbral de temperatura por dispositivo, una regla que detecta sensores que dejan de reportar y el enrutamiento de notificaciones, y al final las compararás con las reglas de umbral integradas en el portal de ConnectMQ.

Requisitos previos

Esta guía parte del stack de nuestro tutorial del stack TIG con Docker Compose, en el que Telegraf se suscribe a topics MQTT en broker.connectmq.com y escribe en InfluxDB 2. El modelo de datos es:

Cualquier fuente de datos InfluxDB en Grafana 10 u 11 funciona igual. Si tus datos llegan a través de un puente en Python, como se describe en cómo almacenar datos MQTT en InfluxDB, solo cambia el nombre del measurement en las consultas.

Cómo evalúa las reglas el sistema de alertas de Grafana

Las alertas de Grafana se ejecutan en el servidor de Grafana, no en tu navegador, y funcionan de forma independiente de los dashboards. Todas las reglas siguen el mismo proceso:

1. Consulta. Obtiene datos recientes de la fuente de datos, por ejemplo las temperaturas de los últimos diez minutos.
2. Expresiones. Reduce cada serie a un único número, como el último valor o la media, y lo compara con un umbral.
3. Evaluación. La regla se ejecuta a un intervalo fijo definido por su grupo de evaluación.
4. Periodo de espera (pending period). La condición debe mantenerse verdadera durante este tiempo antes de que la alerta se dispare, lo que filtra lecturas aisladas con ruido.
5. Notificación. Las alertas disparadas y resueltas se enrutan mediante políticas de notificación hacia puntos de contacto como correo electrónico, Slack, Microsoft Teams, Telegram o un webhook.

La propiedad más importante para IoT es que las reglas son multidimensionales. Si la consulta devuelve una serie por dispositivo, Grafana crea una instancia de alerta por dispositivo. Así, una sola regla cubre toda tu flota y la notificación te indica exactamente qué sensor está afectado.

Regla 1: umbral de temperatura por dispositivo

En Grafana, abre Alerting, luego Alert rules y después New alert rule.

Nombre: High temperature

Consulta A (fuente de datos 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)

La llamada a group es lo que hace que la regla sea multidimensional: cada dispositivo se convierte en su propia serie y en su propia instancia de alerta. Promediar en ventanas de un minuto suaviza el ruido de medición antes de aplicar el umbral.

Expresión B: Reduce. Entrada A, función Last, modo "Drop non-numeric values". Esto convierte cada serie en su media de un minuto más reciente.

Expresión C: Threshold. Entrada B, is above 30. Establece C como condición de la alerta.

Carpeta y etiquetas. Coloca la regla en una carpeta como IoT y añade la etiqueta severity=warning. Las etiquetas determinan más adelante el enrutamiento de las notificaciones.

Comportamiento de evaluación. Crea un grupo de evaluación llamado sensors-1m con un intervalo de 1 minuto y fija el periodo de espera en 5 minutos. Así, la alerta solo se dispara cuando un dispositivo ha promediado más de 30 grados durante cinco evaluaciones consecutivas.

Anotaciones. Añade un resumen que indique el dispositivo y el valor:

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

Haz clic en Save rule and exit. En menos de un minuto, la lista de reglas muestra una instancia por dispositivo en estado Normal.

Regla 2: detectar sensores que dejan de reportar

Un sensor que se estropea no envía un valor alto; no envía nada. Las reglas de umbral no pueden detectarlo por sí solas, y en la práctica los sensores silenciosos están entre los fallos IoT más habituales. Hay dos enfoques complementarios.

Opción A: configurar la gestión de datos ausentes

En cada regla, la sección de evaluación tiene un ajuste para lo que ocurre cuando la consulta no devuelve datos. Las opciones son No Data, Alerting, Normal y Keep Last State. Para una regla de un solo dispositivo, basta con elegir Alerting. Para una regla multidimensional no es suficiente, porque la consulta sigue devolviendo datos de los dispositivos sanos, de modo que un único dispositivo silencioso no provoca en absoluto un estado sin datos.

Opción B: alertar según la antigüedad de los datos por dispositivo

Calcula cuántos segundos han pasado desde la última lectura de cada dispositivo y dispara una alerta cuando ese valor sea demasiado alto:

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

Usa Reduce Last como expresión B y Threshold "is above 120" como expresión C, con un periodo de espera de 2 minutos. Elige el umbral en función del intervalo de publicación del dispositivo: unas cuatro veces ese intervalo es un buen punto de partida, de modo que un sensor que publica cada 30 segundos se marca tras dos minutos sin datos. Un dispositivo que lleva más de una hora en silencio desaparece por completo de la consulta, así que configura también el comportamiento sin datos de esta regla como Alerting; eso cubre el caso en que toda la flota deja de enviar.

Regla 3: enrutar las notificaciones

Crea un punto de contacto en Alerting, luego Contact points. Slack, Microsoft Teams, Telegram y los webhooks genéricos solo necesitan una URL o un token. El correo electrónico requiere configurar SMTP en el servidor de Grafana; con Docker, añádelo como variables de entorno:

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

Después abre Notification policies y añade una política hija que coincida con severity=warning y envíe a tu punto de contacto. Agrupa las notificaciones por alertname y line para que diez sensores sobrecalentados en la misma línea generen un solo mensaje en lugar de diez. Usa mute timings para las ventanas de mantenimiento planificadas en las que se espera que los sensores estén desconectados.

Prueba la alerta de extremo a extremo

No esperes a un fallo real para saber si las alertas funcionan. Publica lecturas elevadas para un dispositivo con un ID de prueba único:

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 aproximadamente un minuto, la instancia sensor-test pasa a Pending. Tras el periodo de espera de cinco minutos cambia a Firing y llega la notificación. Detén el bucle y deberían ocurrir dos cosas más: la alerta de temperatura alta se resuelve y, tras dos minutos sin datos, la regla de sensor inactivo se dispara para sensor-test. Esa única prueba valida toda la cadena, desde el broker hasta la notificación. El simulador de dispositivos MQTT es útil para pruebas más largas, ya que sus dispositivos defectuosos generan picos ocasionales.

Lista de comprobación para el ajuste fino

1. Suaviza las señales con ruido mediante aggregateWindow antes de aplicar umbrales.
2. Usa un periodo de espera de varios intervalos de evaluación para ignorar picos puntuales.
3. Agrupa solo por tags estables, para que cada instancia de alerta corresponda a un dispositivo real.
4. Gestiona el silencio de forma explícita con una regla de antigüedad de datos y una configuración sensata de datos ausentes.
5. Agrupa las notificaciones por línea o por planta para evitar avalanchas de alertas.
6. Exporta las reglas terminadas a YAML desde el menú de la regla y guárdalas en control de versiones, para que un Grafana reconstruido pueda aprovisionarlas desde archivos.

Alertas de Grafana frente a reglas de alerta por umbral de ConnectMQ

ConnectMQ también ofrece reglas de alerta por umbral en su portal, con las alertas disparadas registradas en un registro de alertas. Ambos enfoques se sitúan en puntos distintos del flujo de datos y se complementan.

Una combinación práctica es usar las reglas de umbral del portal mientras se ponen en marcha los dispositivos y aún no existe base de datos, y añadir reglas de Grafana cuando el histórico y las notificaciones de guardia empiezan a importar. Ambos leen los mismos topics y ninguno requiere cambios en los dispositivos. Si además quieres ver el estado de alerta sobre la propia planta en lugar de en una tabla, un gemelo digital 3D puede suscribirse a esos mismos topics y resaltar el sensor afectado.

Para la parte de ingesta, la guía del consumidor MQTT de Telegraf explica en detalle la configuración de entrada, y la guía de librerías cliente MQTT te ayuda cuando escribes el código de los dispositivos. La propia documentación de alertas de Grafana cubre todas las opciones de las reglas.

Empieza con ConnectMQ

Puedes crear y probar estas alertas hoy mismo con el servidor MQTT público gratuito de broker.connectmq.com y datos simulados; ese servidor es solo para pruebas y prototipos, no para datos de producción. Para producción, conecta tus dispositivos a un broker MQTT gestionado con TLS y credenciales privadas. ConnectMQ te ofrece ese broker y además un portal con explorador de topics en vivo, dashboard y reglas de alerta por umbral. Crea un broker Serverless gratuito en app.connectmq.com sin tarjeta de crédito y conecta Telegraf con las credenciales generadas.

Preguntas frecuentes

¿Puede una sola regla de alerta de Grafana cubrir todos mis sensores IoT?

Sí. Agrupa la consulta por un tag de dispositivo y Grafana creará una instancia de alerta independiente para cada dispositivo, todo a partir de una única regla.

¿Cómo genero una alerta cuando un sensor deja de enviar datos?

Calcula en la consulta la antigüedad de la última lectura de cada dispositivo y dispara la alerta cuando supere unos cuantos intervalos de publicación. La gestión de datos ausentes por sí sola no detecta un único dispositivo silencioso en una regla multidispositivo.

¿Qué periodo de espera debo usar para las alertas de sensores?

Empieza con entre tres y cinco intervalos de evaluación. Los periodos más cortos reaccionan antes, pero producen más falsas alarmas por lecturas con ruido.

¿Necesito Grafana si mi broker ya tiene alertas por umbral?

No para umbrales simples. Grafana aporta valor cuando necesitas tendencias, ventanas temporales, comprobaciones de antigüedad de datos y enrutamiento hacia canales de guardia.