IoT Sensör Verisi için Grafana Alarmları: Eşikler, Sessiz Sensörler ve Bildirimler

IoT sensör verisi için Grafana alarmları, birinin sürekli izlemesi gereken bir dashboard'u, bir şeyler ters gittiğinde size haber veren bir sisteme dönüştürür. Bu eğitimde InfluxDB'de saklanan MQTT sensör okumaları üzerinde alarm kuralları oluşturacaksınız: cihaz başına bir sıcaklık eşiği, veri göndermeyi bırakan sensörleri yakalayan bir kural ve bildirim yönlendirme; ardından ConnectMQ portalındaki yerleşik eşik kurallarıyla bir karşılaştırma gelecek.

Ön Koşullar

Bu rehber, Telegraf'ın broker.connectmq.com üzerindeki MQTT topic'lerine abone olup InfluxDB 2'ye yazdığı Docker Compose ile TIG stack eğitimimizdeki stack'in üzerine kuruludur. Veri modeli şöyledir:

Grafana 10 veya 11'deki herhangi bir InfluxDB veri kaynağı aynı şekilde çalışır. Veriniz bunun yerine MQTT verisini InfluxDB'ye kaydetme yazısında anlatılan bir Python köprüsünden geliyorsa, sorgularda yalnızca measurement adı değişir.

Grafana Alerting Kuralları Nasıl Değerlendirir

Grafana alerting tarayıcınızda değil Grafana sunucusunda çalışır ve dashboard'lardan bağımsızdır. Her kural aynı hattı izler:

1. Sorgu. Veri kaynağından yakın tarihli veriyi çeker; örneğin son on dakikanın sıcaklıklarını.
2. İfadeler. Her seriyi son değer ya da ortalama gibi tek bir sayıya indirger ve bir eşikle karşılaştırır.
3. Değerlendirme. Kural, değerlendirme grubunun tanımladığı sabit bir aralıkta çalışır.
4. Bekleme süresi (pending period). Alarmın tetiklenmesi için bir koşulun bu süre boyunca doğru kalması gerekir; bu da tekil gürültülü okumaları eler.
5. Bildirim. Tetiklenen ve çözülen alarmlar, bildirim politikaları üzerinden e-posta, Slack, Microsoft Teams, Telegram ya da webhook gibi contact point'lere yönlendirilir.

IoT için en önemli özellik, kuralların çok boyutlu olmasıdır. Sorgu cihaz başına bir seri döndürürse Grafana cihaz başına bir alarm örneği oluşturur. Böylece tek bir kural tüm cihaz filonuzu kapsar ve bildirim size tam olarak hangi sensörün etkilendiğini söyler.

Kural 1: Cihaz Başına Sıcaklık Eşiği

Grafana'da Alerting, ardından Alert rules, ardından New alert rule'u açın.

Ad: High temperature

Sorgu A (InfluxDB veri kaynağı, 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)

Kuralı çok boyutlu yapan group çağrısıdır: her cihaz kendi serisi ve kendi alarm örneği olur. Bir dakikalık pencereler üzerinden ortalama almak, eşik uygulanmadan önce ölçüm gürültüsünü yumuşatır.

İfade B: Reduce. Girdi A, fonksiyon Last, mod "Drop non-numeric values". Bu, her seriyi en son bir dakikalık ortalamasına dönüştürür.

İfade C: Threshold. Girdi B, is above 30. C'yi alarm koşulu olarak ayarlayın.

Klasör ve etiketler. Kuralı IoT gibi bir klasöre koyun ve severity=warning etiketi ekleyin. Etiketler daha sonra bildirim yönlendirmesini belirler.

Değerlendirme davranışı. 1 dakika aralıklı sensors-1m adında bir değerlendirme grubu oluşturun ve bekleme süresini 5 dakika olarak ayarlayın. Böylece alarm yalnızca bir cihazın ortalaması art arda beş değerlendirme boyunca 30 derecenin üzerinde kaldığında tetiklenir.

Açıklamalar (annotations). Cihazı ve değeri belirten bir özet ekleyin:

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

Save rule and exit'e tıklayın. Bir dakika içinde kural listesi, Normal durumda cihaz başına bir örnek gösterir.

Kural 2: Veri Göndermeyi Bırakan Sensörleri Tespit Edin

Arızalanan bir sensör yüksek bir değer göndermez; hiçbir şey göndermez. Eşik kuralları bunu tek başına yakalayamaz ve pratikte sessiz sensörler en yaygın IoT arızaları arasındadır. Birbirini tamamlayan iki yaklaşım vardır.

Seçenek A: veri yok durumunu yapılandırın

Her kuralın değerlendirme bölümünde, sorgu veri döndürmediğinde ne olacağını belirleyen bir ayar bulunur. Seçenekler No Data, Alerting, Normal ve Keep Last State'tir. Tek cihazlı bir kural için bunu Alerting olarak ayarlamak yeterlidir. Çok boyutlu bir kural için ise yeterli değildir; çünkü sorgu sağlıklı cihazlar için hâlâ veri döndürür ve tek bir sessiz cihaz hiç veri yok durumu tetiklemez.

Seçenek B: cihaz başına veri yaşına göre alarm verin

Her cihazın son okumasından bu yana kaç saniye geçtiğini hesaplayın ve bu süre çok uzadığında alarm verin:

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

İfade B olarak Reduce Last, ifade C olarak Threshold "is above 120" kullanın ve bekleme süresini 2 dakika yapın. Eşiği cihazın yayın aralığına göre seçin: aralığın yaklaşık dört katı makul bir başlangıçtır; böylece her 30 saniyede yayın yapan bir sensör iki sessiz dakikanın ardından işaretlenir. Bir saatlik aralıktan daha uzun süre sessiz kalan bir cihaz sorgudan tamamen kaybolur; bu nedenle bu kuralın veri yok davranışını da Alerting olarak ayarlayın. Bu, tüm filonun sessizleştiği durumu yakalar.

Kural 3: Bildirimleri Yönlendirin

Alerting, ardından Contact points altında bir contact point oluşturun. Slack, Microsoft Teams, Telegram ve genel webhook'lar yalnızca bir URL ya da token gerektirir. E-posta ise Grafana sunucusunda SMTP ayarları gerektirir; Docker ile bunları ortam değişkenleri olarak ekleyin:

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

Ardından Notification policies'i açın ve severity=warning ile eşleşip contact point'inize gönderen bir alt politika ekleyin. Bildirimleri alertname ve line ile gruplayın; böylece aynı hattaki on aşırı ısınan sensör on yerine tek bir mesaj üretir. Sensörlerin çevrimdışı olmasının beklendiği planlı bakım pencereleri için mute timing'leri kullanın.

Alarmı Uçtan Uca Test Edin

Alarmların çalışıp çalışmadığını öğrenmek için gerçek bir arızayı beklemeyin. Benzersiz bir test kimliğiyle tek bir cihaz için yüksek okumalar yayınlayın:

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

Yaklaşık bir dakika içinde sensor-test örneği Pending durumuna geçer. Beş dakikalık bekleme süresinin ardından Firing durumuna geçer ve bildirim gelir. Döngüyü durdurun; iki şey daha olmalıdır: yüksek sıcaklık alarmı çözülür ve iki sessiz dakikanın ardından sessiz sensör kuralı sensor-test için tetiklenir. Bu tek test, broker'dan bildirime kadar tüm zinciri kanıtlar. Arızalı cihazları ara sıra ani yükselmeler ürettiği için MQTT cihaz simülatörü daha uzun testlerde faydalıdır.

İnce Ayar Kontrol Listesi

1. Eşikleri uygulamadan önce gürültülü sinyalleri aggregateWindow ile yumuşatın.
2. Tek seferlik ani yükselmeleri yok saymak için birkaç değerlendirme aralığı uzunluğunda bir bekleme süresi kullanın.
3. Her alarm örneğinin gerçek bir cihaza karşılık gelmesi için yalnızca kararlı tag'lere göre gruplayın.
4. Sessizliği bir veri yaşı kuralı ve makul veri yok ayarlarıyla açıkça ele alın.
5. Alarm fırtınalarından kaçınmak için bildirimleri hat ya da tesise göre gruplayın.
6. Tamamlanan kuralları kuralın menüsünden YAML olarak dışa aktarın ve sürüm kontrolünde tutun; böylece yeniden kurulan bir Grafana onları dosyalardan provision edebilir.

Grafana Alerting ve ConnectMQ Eşik Alarm Kuralları

ConnectMQ da portalında eşik alarm kuralları sunar ve tetiklenen alarmlar bir alarm günlüğüne kaydedilir. İki yaklaşım veri hattının farklı noktalarında yer alır ve birbirini tamamlar.

Pratik bir kombinasyon şudur: cihazlar devreye alınırken ve henüz bir veritabanı yokken portalın eşik kurallarını kullanın; geçmiş veri ve nöbet bildirimleri önem kazandığında Grafana kurallarını ekleyin. Her ikisi de aynı topic'leri okur; hiçbiri cihazlarda değişiklik gerektirmez.

Veri alma tarafında Telegraf MQTT consumer rehberi girdi yapılandırmasını ayrıntılı olarak açıklar; cihaz kodu yazarken ise MQTT istemci kütüphaneleri rehberi yardımcı olur. Grafana'nın kendi alerting dokümantasyonu tüm kural seçeneklerini kapsar.

ConnectMQ ile Başlayın

Bu alarmları bugün public MQTT test broker ve simüle edilmiş veriyle oluşturup test edebilirsiniz. Üretim için cihazlarınızı TLS ve özel kimlik bilgileriyle barındırılan bir MQTT broker üzerinde çalıştırın. ConnectMQ size bu broker'ın yanı sıra canlı topic gezgini, dashboard ve eşik alarm kuralları içeren bir portal sunar. app.connectmq.com adresinde kredi kartı gerektirmeden ücretsiz bir Serverless broker oluşturun ve Telegraf'ı üretilen kimlik bilgileriyle bağlayın.

Sık Sorulan Sorular

Tek bir Grafana alarm kuralı tüm IoT sensörlerimi kapsayabilir mi?

Evet. Sorguyu bir cihaz tag'ine göre gruplayın; Grafana tek bir kuraldan her cihaz için ayrı bir alarm örneği oluşturur.

Bir sensör veri göndermeyi bıraktığında nasıl alarm alırım?

Sorguda her cihazın son okumasının yaşını hesaplayın ve birkaç yayın aralığını aştığında alarm verin. Veri yok yönetimi tek başına, çok cihazlı bir kuralda sessizleşen tek bir cihazı yakalamaz.

Sensör alarmları için hangi bekleme süresini kullanmalıyım?

Üç ila beş değerlendirme aralığıyla başlayın. Daha kısa süreler daha hızlı tepki verir ancak gürültülü okumalardan daha fazla yanlış alarm üretir.

Broker'ımda zaten eşik alarmları varsa Grafana'ya ihtiyacım var mı?

Basit eşikler için hayır. Trendlere, zaman pencerelerine, veri yaşı kontrollerine ve nöbet kanallarına yönlendirmeye ihtiyaç duyduğunuzda Grafana değerli hale gelir.