Sık Sorulan Sorular ve Troubleshooting
Configuration-Dependent Değerler
Bu sayfada belirtilen eşik değerleri (paket/dakika limitler, tekrar sayıları, vb.) default değerlerdir. Deployment-specific değerler Eşik Değerleri ve Konfigürasyon bölümünde environment variables ile kontrol edilebilir. Uygulamayı deploy ederken bu değişkenleri ortamınıza göre ayarladığınızdan emin olunuz.
S: Cihaz 500 yanıtı alıyor, nedenini nasıl bulabilirim?
Olası nedenler ve kontrol adımları:
| HTTP 500 Neden | Kontrol Noktası | Çözüm |
|---|---|---|
| Raw DB yazım hatası | Raw tabloya yeni kayıt yoksa | DB bağlantısı, table şeması, auth kontrol et; logs'ta "raw db write failed" ara |
| Normalize işlem hatası | Raw DB OK ama Redis boşsa | Canonical şema dönüşüm loglarını kontrol et; CPS uyumluluğu doğrula |
| Redis yazım hatası | Raw DB + logs OK ama device_buffer empty | Redis bağlantı, key formatı (device_buffer:{device_id}), memory kontrol et |
| Şema doğrulama hatası | Parse OK ama 500 dönüyorsa | CPS validator loglarını kontrol et; payload CPS sözleşmesine uygun mu? |
| Timeout | Hiçbir layer çıktı yok | Network gecikmesi, DB slow query, Redis lag kontrol et |
Debug adımları:
- Application logs'ta
"500"veya"Internal Server Error"ara - Layer hangi aşamada başarısız oldu kontrol et (raw/normalize/redis)
- Cihazın payload'ını manual test et:
curl -X POST ... -d @payload.json - Raw DB, Normalize service ve Redis sağlık kontrol et
S: Duplicate tespiti neden çalışmıyor? Aynı paket tekrar tekrar kabul ediliyor.
Kontrol adımları:
| Sorun | Tanı | Çözüm |
|---|---|---|
| device_time aynı değil | Her pakette device_time değişiyorsa | Cihaz saati senkronize mi? NTP kontrol et |
| Payload hash farklı | Wire payload boyutunda fark varsa (örn. whitespace) | Normalize öncesi payload hash'in same format olduğundan emin ol |
| device_runtime key yok | Redis'te device_runtime:{device_id} diye bir key yoksa | İlk paket başarılı mı? Cihazın device_id doğru mu? |
| Hash algoritma uyumsuzluğu | İki servis farklı hash kullanıyorsa | Tüm servisler SHA256 (ya da aynı algo) kullanıyor mu? |
| Duplicate sayaçları sıfırlanıyor | Sayaçlar reset ediliyor gibi görünüyorsa | Redis TTL ayarları kontrol et; cache invalidation politikası gözden geçir |
Debug adımları:
device_runtime:{device_id}keyi Redis'te kontrol et:redis-cli GET device_runtime:{device_id}- Ardışık iki paket için logs'ta hash değerlerini karşılaştır
- Duplicate event'i Kafka'da görülüyor mu?
device.ingest_duplicate_detected.v1ara - Cihazın
device_timedeğeri gerçekten sabit mi? Üretici firmware'de kontrol et
S: Kafka'ya yazım başarısız olursa ne yapılır? Paket kaybolur mu?
Kısa cevap: Hayır, paket kaybolmaz. Veri Raw DB + Redis'te güvenli tutulur.
Detaylı akış:
Raw DB yazıldı ✅
↓
Normalize yapıldı ✅
↓
Redis güncellendi ✅
↓
Cihaza 200 OK dönüldü ✅
↓
Kafka yazım hatası ❌
↓
→ Çoktan 200 OK döndüğü için cihaz paket göndermez
→ Veri Raw DB + Redis'te kalır
→ Kafka error log + retry queue'ye alınır
→ Manual atau asenkron retry mekanizması devreye girer
Kafka yazım hatasında ne yapılmalı:
- Application logs kontrol et: "kafka emit failed" gibi mesajlar var mı?
- Kafka broker sağlık kontrol et: connectivity, partition availability, replication
- Retry/Outbox mekanizması var mı? Varsa status kontrol et
- Veri kaybı riski yoksa, reprocess flow başlat: raw DB'den Kafka'ya yeniden üretim
- Monitoring alert kur: "Kafka 5+ dakika offline" gibi
öneri: Event mekanizması başarısız olsa bile, downstream services Redis'ten payload'ı okuyabilmeli. Kafka yalnız "tetik" olarak kullanılmalı.
S: Rate limiting / Flood koruma ne zaman devreye girer?
Kontrol adımları:
| Durum | Beklenen Davranış | Kontrol Noktası |
|---|---|---|
| Normal trafiği gelen cihaz | İlk 12 paket/dakika OK | Logs'ta warning yok, events normal |
| Şüpheli trafik (12-30 paket) | warning flag set üretilir | Logs'ta "suspicious rate" var mı? |
| Flood trafiği (>30 paket) | device.ingest_flood_detected.v1 event | Kafka'da flood event var mı? Dashboard'da alarm var mı? |
| Paket aralığı anormal | < expected/4 → warning, < expected/10 → flood | Cihaz aralık hesaplaması yapıyor mu? |
Custom Threshold'lar
Tablodaki değerler (12, 30, 1/4, 1/10) default değerlerdir. Üretim ortamında bu threshold'ları INGEST_RATE_SUSPICIOUS_PER_MINUTE ve
benzeri environment variables ile özelleştirebilirsiniz. Detaylar için
Eşik Değerleri ve Konfigürasyon bölümüne bakınız.
Debug adımları:
events_per_1msayaçı Redis'te var mı? Doğru güncelleniyel mi?- Cihazın beklenen
device_timearalığı (interval) nedir? Config kontrol et - Warning events Kafka'da gözüküyor mu?
device.ingest_*_detectedtopic ara - Dashboard'da flood threshold alarmı aktif mi?
Hard protection (rate limiting) devreye almadan önce:
- En az 1 hafta operasyonel verisi topla
- Cihaz davranışını gözlemle (legitimate burst vs malfunction)
- False positive risk değerlendir (ex: NTP sync burst, network reconnect)
S: Belirli bir cihaz neden devamlı duplicate uyarısı alıyor?
Tanı adımları:
- Cihazın firmware sürümü 1-2 diğer cihazdan farklı mı? → Yazılım hatası ihtimali
- Network koşulları (RSI, packet loss) → Retransmit mi?
- Device time source (NTP, RTC) senkron mi? → Clock drift
- Paket aralığı periyodik mi? → Tasarımsal sorun (stuck loop)
- Raw payload gerçekten aynı mı? (Status, measurements) → Sensor arızası
Operasyonel yaklaşım:
- 1 gün süreyle paketleri kaydet (raw_data table'dan)
- Cihazla iletişim kur: firmware güncellemesi öner
- Stuck threshold'u düşür ve stuck event üreterek uyarı ver
- Replay service ile paketleri yeniden işle (gerekirse)
S: Redis'te device_buffer büyüyor, sorun mu?
Normal sınırlar:
- Bir
device_buffer:{device_id}key ~1-2 KB - 100K cihaz × 2 KB = ~200 MB (gayet normal)
- İğnesi 1000K cihaz × 2 KB = ~2 GB (monitor etmeli)
Buffer büyümesi neden olabilir:
| Neden | Kontrol | Çözüm |
|---|---|---|
buffers.measurements boşalmıyor | Stream service çalışıyor mı? | Downstream service health kontrol et |
buffers.synthesis boşalmıyor | Synthesis işlemesi durmuş mu? | Service logs kontrol et, restart et |
buffers.window kalıyor | Windowing service neden çalışmıyor? | Cron job / scheduler kontrol et |
| TTL yok | Key'lerde TTL tanımlanmamış mı? | Redis key policy kontrol et; buffer cleanup cron ekle |
Tavsiye:
- Her buffer'a inactive cleanup cron kur (24 saat sonra boşla)
- Redis memory threshold warning kur (80% trigger)
- Monthly buffer cleanup job (backpressure handling)
S: Hangi metrikleri izlemeliyim?
Temel monitoring dashboard:
| Metrik | Uyarı Eşiği | Örnek Query |
|---|---|---|
| Ingest latency (p95) | > 500ms | histogram_quantile(0.95, ingest_process_duration_ms) |
| Raw DB yazım hataları | > 10/dakika | rate(raw_db_write_errors[1m]) |
| Duplicate rate | > 5% of traffic | rate(duplicate_packets[1m]) / rate(total_packets[1m]) |
| Flood detections/saat | > 5 | rate(flood_warnings[1h]) |
| Stuck cihaz sayısı | > 10 | count(stuck_cihazlar) |
| Kafka emit başarısızlık | > 1% | rate(kafka_emit_errors[1m]) |
| Redis availability | < 99.9% | redis_up{instance="ingest"} |
| Request/saniye | Baseline üstü %50+ | rate(http_requests_total[1m]) |
Önerilen alerts:
- "p95 latency > 1s" → Infrastructure issue
- "raw_db errors > 50/min" → Database problem
- "duplicate rate > 10%" → Hardware/firmware issue
- "stuck_devices > 20" → Fleet health alarm
- "kafka offline > 5min" → Critical outage
S: Flow diyagramlarını detaylı görmek için hangisine bakmalıyım?
Her diyagram için rehber:
- Ana Paket İşlem Akışı → 6-layer tam işlem adımları + ACK semantiği
- Hata ve Karar Akışı → Parse hatası, şema hatası, duplicate, rate kararları
- Duplicate / Stuck / Flood Karar → Hangi koşulda duplicate/stuck/flood sayılır (tekrar sayısı, interval eşikleri)
- Veri Katmanları Yazım Sırası → Raw DB → Normalize → Redis → Kafka sırası (zorunluluk seviyeleri)