Os alertas do Grafana para dados de sensores IoT transformam um dashboard que alguém precisa ficar vigiando em um sistema que avisa quando algo dá errado. Neste tutorial você vai criar regras de alerta sobre leituras de sensores MQTT armazenadas no InfluxDB: um limite de temperatura por dispositivo, uma regra que detecta sensores que pararam de reportar e o roteamento de notificações, seguidos de uma comparação com as regras de limite integradas ao portal da ConnectMQ.
Pré-requisitos
Este guia parte da stack do nosso tutorial da stack TIG com Docker Compose, em que o Telegraf assina topics MQTT no servidor MQTT público (broker.connectmq.com) e grava no InfluxDB 2. O modelo de dados é:
| Elemento | Valor |
|---|---|
| Bucket | sensors |
| Measurement | sensor |
| Tags | device, line |
| Fields | temperature, humidity |
| Topics de origem | connectmq/demo/<run-id>/<line>/<device>/telemetry |
Qualquer data source InfluxDB no Grafana 10 ou 11 funciona da mesma forma. Se os seus dados vierem de uma ponte em Python, como descrito em armazenar dados MQTT no InfluxDB, só o nome do measurement nas consultas muda.
Como o Grafana Alerting avalia as regras
O Grafana Alerting roda no servidor do Grafana, não no seu navegador, e funciona de forma independente dos dashboards. Toda regra segue o mesmo pipeline:
- Consulta. Busca dados recentes do data source, por exemplo os últimos dez minutos de temperaturas.
- Expressões. Reduz cada série a um único número, como o último valor ou a média, e o compara com um limite.
- Avaliação. A regra é executada em um intervalo fixo definido pelo seu evaluation group.
- Pending period. A condição precisa permanecer verdadeira por esse tempo antes de o alerta disparar, o que filtra leituras isoladas com ruído.
- Notificação. Alertas disparados e resolvidos são roteados por notification policies para contact points como e-mail, Slack, Microsoft Teams, Telegram ou um webhook.
A propriedade mais importante para IoT é que as regras são multidimensionais. Se a consulta retornar uma série por dispositivo, o Grafana cria uma instância de alerta por dispositivo. Uma única regra cobre, portanto, toda a sua frota, e a notificação diz exatamente qual sensor foi afetado.
Regra 1: limite de temperatura por dispositivo
No Grafana, abra Alerting, depois Alert rules, depois New alert rule.
Nome: High temperature
Consulta A (data source 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)
É a chamada group que torna a regra multidimensional: cada dispositivo vira sua própria série e sua própria instância de alerta. Calcular a média em janelas de um minuto suaviza o ruído de medição antes de o limite ser aplicado.
Expressão B: Reduce. Entrada A, função Last, modo "Drop non-numeric values". Isso transforma cada série na sua média de um minuto mais recente.
Expressão C: Threshold. Entrada B, is above 30. Defina C como a condição do alerta.
Pasta e labels. Coloque a regra em uma pasta como IoT e adicione um label severity=warning. Os labels conduzem o roteamento das notificações mais adiante.
Comportamento de avaliação. Crie um evaluation group chamado sensors-1m com intervalo de 1 minuto e defina o pending period como 5 minutos. O alerta então só dispara quando um dispositivo mantém média acima de 30 graus por cinco avaliações consecutivas.
Anotações. Adicione um resumo que identifique o dispositivo e o valor:
{{ $labels.device }} on {{ $labels.line }} is at {{ printf "%.1f" $values.B.Value }} °C
Clique em Save rule and exit. Em um minuto, a lista de regras mostra uma instância por dispositivo no estado Normal.
Regra 2: detecte sensores que pararam de reportar
Um sensor que morre não envia um valor alto; ele não envia nada. Regras de limite não conseguem detectar isso sozinhas e, na prática, sensores silenciosos estão entre as falhas de IoT mais comuns. Existem duas abordagens complementares.
Opção A: configure o tratamento de ausência de dados
Em toda regra, a seção de avaliação tem uma configuração para o que acontece quando a consulta não retorna dados. As opções são No Data, Alerting, Normal e Keep Last State. Para uma regra de um único dispositivo, defini-la como Alerting é suficiente. Para uma regra multidimensional não é, porque a consulta continua retornando dados dos dispositivos saudáveis, então um único dispositivo silencioso nem chega a gerar um estado de ausência de dados.
Opção B: alerte com base na idade dos dados por dispositivo
Calcule quantos segundos se passaram desde a última leitura de cada dispositivo e alerte quando esse valor ficar grande demais:
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 }))
Use Reduce Last como expressão B e Threshold "is above 120" como expressão C, com pending period de 2 minutos. Escolha o limite a partir do intervalo de publicação do dispositivo: cerca de quatro vezes o intervalo é um bom ponto de partida, então um sensor que publica a cada 30 segundos é sinalizado após dois minutos em silêncio. Um dispositivo silencioso há mais tempo que o intervalo de uma hora some completamente da consulta, então defina também o comportamento de ausência de dados desta regra como Alerting, o que cobre o caso em que a frota inteira fica em silêncio.
Regra 3: roteie as notificações
Crie um contact point em Alerting, depois Contact points. Slack, Microsoft Teams, Telegram e webhooks genéricos precisam apenas de uma URL ou token. O e-mail exige configurações de SMTP no servidor do Grafana; com Docker, adicione-as como variáveis de ambiente:
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
Depois abra Notification policies e adicione uma política filha que corresponda a severity=warning e envie para o seu contact point. Agrupe as notificações por alertname e line para que dez sensores superaquecidos na mesma linha, digamos de um frigorífico ou de uma planta em Manaus, gerem uma mensagem em vez de dez. Use mute timings para janelas de manutenção planejada, quando se espera que os sensores fiquem offline.
Teste o alerta de ponta a ponta
Não espere uma falha real para descobrir se os alertas funcionam. Publique leituras elevadas para um dispositivo com um ID de teste ú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
Em cerca de um minuto, a instância sensor-test passa para Pending. Depois do pending period de cinco minutos, ela muda para Firing e a notificação chega. Pare o loop e mais duas coisas devem acontecer: o alerta de alta temperatura é resolvido e, após dois minutos de silêncio, a regra de sensor parado dispara para sensor-test. Esse único teste comprova a cadeia completa, do broker à notificação. O simulador de dispositivos MQTT é útil para testes mais longos, já que seus dispositivos com defeito produzem picos ocasionais.
Checklist de ajuste fino
- Suavize sinais ruidosos com
aggregateWindowantes de aplicar limites. - Use um pending period de vários intervalos de avaliação para ignorar picos isolados.
- Agrupe apenas por tags estáveis, para que cada instância de alerta corresponda a um dispositivo real.
- Trate o silêncio explicitamente com uma regra de idade dos dados e configurações sensatas de ausência de dados.
- Agrupe notificações por linha ou site para evitar tempestades de alertas.
- Exporte as regras prontas para YAML pelo menu da regra e mantenha-as no controle de versão, para que um Grafana reconstruído possa provisioná-las a partir de arquivos.
Grafana Alerting vs. regras de alerta por limite da ConnectMQ
A ConnectMQ também oferece regras de alerta por limite no seu portal, com os alertas disparados registrados em um log de alertas. As duas abordagens ficam em pontos diferentes do pipeline e se complementam.
| Aspecto | Grafana Alerting | Regras de alerta por limite da ConnectMQ |
|---|---|---|
| Onde roda | Servidor do Grafana, sobre dados armazenados | Portal do broker, sobre valores MQTT recebidos |
| Exige banco de dados | Sim, como o InfluxDB | Não |
| Lógica de janela de tempo | Agregações, pending periods, idade dos dados | Limites simples sobre valores |
| Roteamento de notificações | Contact points e políticas | Log de alertas no portal |
| Esforço de configuração | Maior, parte de uma stack TIG | Baixo, configurado no portal |
| Ideal para | Tendências, regras para a frota inteira, roteamento de plantão | Visibilidade rápida durante o comissionamento e em implantações pequenas |
Uma combinação prática é usar as regras de limite do portal enquanto os dispositivos estão sendo comissionados e ainda não existe banco de dados, e adicionar regras no Grafana quando histórico e notificações de plantão passarem a importar. Ambas leem os mesmos topics; nenhuma exige mudanças nos dispositivos.
Para o lado da ingestão, o guia do Telegraf MQTT consumer explica a configuração do input em detalhes, e o guia de bibliotecas de cliente MQTT ajuda quando você escreve o código dos dispositivos. A própria documentação de alertas do Grafana cobre todas as opções de regra.
Comece com a ConnectMQ
Você pode criar e testar esses alertas hoje mesmo usando o servidor MQTT público (gratuito) e dados simulados; ele serve para testes e protótipos, não para dados de produção. Para produção, rode os seus dispositivos em um broker MQTT gerenciado com TLS e credenciais privadas. A ConnectMQ oferece esse broker e também um portal com explorador de topics ao vivo, dashboard e regras de alerta por limite. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, e conecte o Telegraf com as credenciais geradas.
Perguntas frequentes
Uma única regra de alerta do Grafana pode cobrir todos os meus sensores IoT?
Sim. Agrupe a consulta por uma tag de dispositivo e o Grafana cria uma instância de alerta separada para cada dispositivo, tudo a partir de uma única regra.
Como alerto quando um sensor para de enviar dados?
Calcule na consulta a idade da última leitura de cada dispositivo e alerte quando ela ultrapassar alguns intervalos de publicação. O tratamento de ausência de dados sozinho não detecta um único dispositivo silencioso em uma regra com vários dispositivos.
Qual pending period devo usar para alertas de sensores?
Comece com três a cinco intervalos de avaliação. Períodos mais curtos reagem mais rápido, mas geram mais alarmes falsos a partir de leituras ruidosas.
Preciso do Grafana se o meu broker já tem alertas por limite?
Não para limites simples. O Grafana passa a valer a pena quando você precisa de tendências, janelas de tempo, verificações de idade dos dados e roteamento para canais de plantão.
