Alarm Yanlis Pozitifler

Alarm sisteminin gereksiz yere tetiklenmesi, yanlis offline bildirimleri ve tekrar eden alarm sorunlarinin teshis ve cozum rehberi.

Sorun Tablosu

Semptom	Olasi Sebep	Kontrol	Cozum
Surekli alarm uretiyor	Esik cok dusuk/yuksek	Alarm policy threshold kontrol	Threshold guncelle
Offline alarm yanlis	Connection check suresi cok kisa	check_device_offline task sikligi	Timeout suresini artir (default 5dk)
Gecici spike'larda alarm	Debounce/hysteresis yok	Alarm engine mantigi	min_duration parametresi ekle
Ayni alarm tekrar tekrar	Snooze calismiyor	check_snoozed task	Celery worker aktif mi kontrol et

---

Detayli Teshis ve Cozumler

1. Surekli Alarm Uretiyor

Semptom: Belirli bir cihaz veya sensor icin dakikada bircok alarm bildirimi geliyor. Kullanicilar bildirim yogunlugundan sikayet ediyor.

Olasi Sebepler:

• Alarm esik degeri gercekci degil (ornegin inverter sicakligi icin max 30°C — normal calismada bile asiyor)
• Sensor kalibrasyon hatasi — olcum degeri sapmali
• Alarm policy'de hysteresis (gecikme bandi) tanimlanmamis
• Alarm tetiklenme kosulu her olcumde yeniden degerlendiriliyor

Kontrol Adimlari:

# 1. Alarm policy'yi kontrol et
# backend/app/features/alarms/

# Alarm tanimi ornegi:
{
    "device_id": 42,
    "metric": "temperature",
    "condition": "above",
    "threshold": 30.0,        # ← Bu deger gercekci mi?
    "severity": "warning",
    "hysteresis": 0.0          # ← Hysteresis 0 ise her geciste tetiklenir
}

-- 2. Son alarm gecmisine bak
SELECT created_at, device_id, metric, value, threshold
FROM alarm_events
WHERE device_id = 42
ORDER BY created_at DESC
LIMIT 20;

-- Eger degerler esik etrafinda saliniyor:
-- 30.1, 29.9, 30.2, 29.8, 30.1 ...
-- → Hysteresis gerekli

# 3. Sensor verisini analiz et — normal calısma araligi nedir?
# TimescaleDB'den son 24 saatlik veri:
docker compose exec postgres psql -U zeus -c "
  SELECT min(value), avg(value), max(value), stddev(value)
  FROM measurements
  WHERE device_id = 42
    AND metric = 'temperature'
    AND time > now() - interval '24 hours';
"

Cozum:

1. Threshold ayarlama: Sensor verilerinin istatistiksel analizine gore gercekci esik degeri belirleyin. Ornegin ortalama + 2 standart sapma
2. Hysteresis ekleme: Alarm tetiklendikten sonra deger threshold - hysteresis altina dusmedikce yeni alarm olusturmayin

   # Ornek: threshold=45°C, hysteresis=3°C
   # Alarm tetiklenir: value >= 45°C
   # Alarm kapanir: value < 42°C (45 - 3)
   # Bu aralıkta (42-45) yeni alarm uretilmez

3. Bildirim sinirlama: Ayni alarm icin belirli bir sure icinde (ornegin 15 dakika) sadece tek bildirim gonderin
4. Sensor kalibrasyon: Sensor degerleri gercek olcum cihazi ile karsilastirarak sapma olup olmadigini kontrol edin

---

2. Offline Alarm Yanlis Tetikleniyor

Semptom: Cihaz aslinda cevrimici ve veri gonderiyor ama "cihaz cevrimdisi" alarmi tetikleniyor.

Olasi Sebepler:

• check_device_offline Celery task'i cihazin son veri gonderdigi zamani cok kisa bir pencereyle kontrol ediyor
• Cihaz veri gonderme araligi (polling interval) offline kontrol suresinden uzun
• Ag gecikmeleri veya MQTT broker gecici kesintileri
• Zaman dilimi (timezone) uyumsuzlugu — UTC vs yerel saat

Kontrol Adimlari:

# 1. Offline kontrol task'inin suresini kontrol et
# backend/app/tasks/ veya backend/app/features/alarms/

# Ornek offline kontrol mantigi:
OFFLINE_THRESHOLD_MINUTES = 5  # ← Bu sure yeterli mi?

async def check_device_offline():
    devices = await get_all_active_devices()
    for device in devices:
        last_seen = device.last_telemetry_at
        if (now() - last_seen) > timedelta(minutes=OFFLINE_THRESHOLD_MINUTES):
            await create_alarm(device, "offline")

# 2. Cihazin gercek veri gonderme sikligini kontrol et
docker compose exec postgres psql -U zeus -c "
  SELECT time, value
  FROM measurements
  WHERE device_id = 42
  ORDER BY time DESC
  LIMIT 10;
"
# Veri gonderme araligi 3 dakikaysa ve offline threshold 5 dakikaysa
# → Ag gecikmesiyle birlikte yanlis alarm tetiklenebilir

# 3. Celery task calisma gecmisini kontrol et
docker compose exec celery-worker celery -A app inspect active
docker compose exec celery-worker celery -A app inspect scheduled

Cozum:

1. Timeout artirma: OFFLINE_THRESHOLD_MINUTES degerini cihazin veri gonderme araliginin en az 3 kati yapin. Ornegin veri her 1 dakikada geliyorsa offline threshold 5 dakika olsun
2. Grace period: Offline alarm tetiklenmeden once 2 ardisik kontrol baskisiz gecmeli (ilk kontrol → uyari, ikinci kontrol → alarm)
3. Timezone duzeltme: Tum zaman karsilastirmalarinin UTC uzerinden yapildigindan emin olun
4. Heartbeat mekanizmasi: Telemetri verisine ek olarak cihazdan duzenli heartbeat mesaji alin — sadece heartbeat kesildiginde offline alarm tetikleyin

---

3. Gecici Spike'larda Alarm

Semptom: Sensor verisi cok kisa sureligine (1-2 saniye) esigi asiyor ve alarm tetikleniyor. Deger hemen normale donuyor ama bildirim gidmis oluyor.

Olasi Sebepler:

• Sensor okuma hatasi (noise, EMI, kalibrasyon sorunu)
• Alarm engine'de debounce veya minimum sure kontrolu yok
• Guc dalgalanmasi sensor ciktisinda gecici spike olusturuyor
• Modbus okuma hatasi gecici yanlis deger donduruyor

Kontrol Adimlari:

-- Spike'lari tespit et: esigi asan ama kisa sureli degerler
SELECT time, value
FROM measurements
WHERE device_id = 42
  AND metric = 'temperature'
  AND value > 45.0  -- alarm esigi
  AND time > now() - interval '24 hours'
ORDER BY time;

-- Eger spike sureleri 1-2 olcumle sinirli ve hemen normale donuyorsa
-- → Gecici spike, debounce gerekli

# Alarm engine'de min_duration kontrolu var mi?
# Dogru yaklaşım:
if value > threshold:
    if alarm_start_time is None:
        alarm_start_time = now()
    elif (now() - alarm_start_time) >= min_duration:
        trigger_alarm()  # En az min_duration sure esik asilmis
else:
    alarm_start_time = None  # Deger normale dondu, sayaci sifirla

Cozum:

1. min_duration parametresi: Alarm tetiklenmesi icin deger esigi en az X saniye/dakika boyunca asmali. Onerilen minimum: 30 saniye — 2 dakika

   alarm_policy = {
       "threshold": 45.0,
       "min_duration_seconds": 60,  # 60 saniye surekli asmalı
   }

2. Hareketli ortalama: Son N okumanin ortalamasini alarm degerlendirmesinde kullanin (ornegin son 5 okumanin ortalaması)
3. Outlier filtreleme: Onceki degerlerden cok buyuk sapma gosteren tek bir okuma varsa (ornegin 3 sigma) alarm degil uyari uretsin
4. Sensor kalibrasyon: Surekli spike ureten sensorleri fiziksel olarak kontrol ettirin

---

4. Ayni Alarm Tekrar Tekrar Tetikleniyor

Semptom: Bir alarm bir kez onaylanmis (acknowledged) veya snooze edilmis olmasina ragmen birkaç dakika sonra tekrar tetikleniyor.

Olasi Sebepler:

• Snooze mekanizmasi calismıyor — Celery worker durdurulmus veya mesgul
• Alarm engine snooze durumunu kontrol etmiyor
• Alarm state machine'de "acknowledged" → "resolved" gecisi bozuk
• Birden fazla Celery worker ayni alarmi degerlendiriyor (race condition)

Kontrol Adimlari:

# 1. Celery worker durumunu kontrol et
docker compose ps celery-worker celery-beat

# 2. Aktif task'lari listele
docker compose exec celery-worker celery -A app inspect active

# 3. Alarm queue'sunda birikmis task var mi?
docker compose exec redis redis-cli LLEN celery

# 4. Alarm state machine'i kontrol et
# Beklenen alarm durumlari:
# ACTIVE → ACKNOWLEDGED → RESOLVED
# ACTIVE → SNOOZED (sure dolunca tekrar ACTIVE)
# ACTIVE → RESOLVED (deger normale dondu)

# Snooze kontrolu:
async def evaluate_alarm(device_id, metric, value):
    existing = await get_active_alarm(device_id, metric)
    if existing:
        if existing.status == "snoozed" and existing.snooze_until > now():
            return  # Snooze suresi dolmamis, alarm uretme
        if existing.status == "acknowledged":
            return  # Zaten onaylanmis, tekrar alarm uretme

Cozum:

1. Celery worker restart: docker compose restart celery-worker celery-beat
2. Snooze kontrolu: Alarm degerlendirme fonksiyonunda mevcut alarm durumunun (snoozed, acknowledged) kontrol edildiginden emin olun
3. Tekil alarm zorunlulugu: Ayni cihaz + metric + severity kombinasyonu icin aktif alarm varsa yeni alarm olusturmayin
4. Race condition onleme: Alarm degerlendirme isleminde Redis distributed lock kullanarak ayni anda birden fazla worker'in ayni alarmi islemesinini engelleyin

   async with redis_lock(f"alarm_eval:{device_id}:{metric}", timeout=30):
       await evaluate_alarm(device_id, metric, value)

---

Alarm Sistemi En Iyi Pratikler

1. Threshold belirleme: Ilk kurulumda 1 hafta veri toplayarak istatistiksel analiz yapin, sonra esik belirleyin
2. Hysteresis: Her alarm policy'sinde threshold degerinin %5-10'u kadar hysteresis bandi tanimlayın
3. Debounce: Minimum 30 saniye — 2 dakika debounce suresi kullanin
4. Bildirim sinirlama: Ayni alarm icin saat basina maksimum bildirim sayisi belirleyin
5. Severity katmanlama: Warning (uyari) ve Critical (kritik) seviyeleri ayirin — sadece critical icin SMS/WhatsApp gonderin
6. Otomatik cozum: Deger normale dondugunde alarmi otomatik "resolved" yapin ve kullaniciyi bilgilendirin