Kamera Sağlık İzleme: SNMP, ONVIF Olayları ve Görüntü Kaybı Alarmı

Kamera ping’e cevap veriyor, izleme ekranı yeşil, ama olaydan sonra kayda bakıldığında üç gün boyunca siyah ekran var. Lens spreyle kapatılmış, odak kaymış, IR yanmış ya da VMS akışı hiç alamamış olabilir; ping bunların hiçbirini görmez. Aşağıda kamera sistemlerinde switch portundan görüntü kalitesine kadar uzanan katmanlı bir sağlık izleme modelini, hangi metriğin nereden okunacağını ve alarm eşiklerinin sahada nasıl kurulduğunu anlatıyoruz.

Ping yetmez: katmanlı izleme modeli

Kamera sağlığını tek bir “up/down” durumuna indirgerseniz kaydın olmadığını ancak olay sonrası geriye dönük inceleme yaparken öğrenirsiniz. Doğru yaklaşım kamerayı beş katmanda izlemektir. Her katman alttakinin sağlam olduğunu varsayar; alarmlar da bu sırayla bastırılır. Switch portu kapalıysa ayrıca “akış yok” alarmı üretilmez.

1. Fiziksel ve güç katmanı: Switch portu bağlı mı, PoE gücü veriliyor mu, port hata sayaçları artıyor mu?
2. Ağ katmanı: Kamera IP’si erişilebilir mi, gecikme ve paket kaybı kabul edilebilir mi?
3. Servis katmanı: RTSP ve ONVIF servisleri yanıt veriyor mu, kimlik doğrulama geçiyor mu, saat senkron mu?
4. Akış ve kayıt katmanı: VMS/NVR akışı alıyor mu, kayıt diske yazılıyor mu, kare hızı ve bitrate beklenen aralıkta mı?
5. Görüntü katmanı: Sahne hâlâ planlanan alanı gösteriyor mu; kapatma, bulanıklık, aşırı karanlık veya açı değişimi var mı?

İlk iki katman ağ izleme sisteminden (Zabbix, LibreNMS, PRTG vb.), üçüncü ve dördüncü katman VMS’in sağlık modülünden veya API’sinden, beşincisi kameranın kendi analitiğinden ya da VMS’in görüntü kalitesi kontrolünden gelir. Sahada en sık gördüğümüz hata, bu kaynakların ayrı ekranlarda ayrı isimlerle durmasıdır: switch “Gi1/0/14 down” der, VMS “Kanal 37 bağlantı yok” der, kimse ikisinin aynı kamera olduğunu bilmez. Her kamera envanterdeki tek bir kimlikle eşleşmeli, alarmlar tek akışta toplanmalı.

İzlenecek metrikler tablosu

Tablo, her katman için önerilen metrikleri ve tipik kaynağı gösterir. Her metrik her üründe yoktur. Kurulumdan önce kamera, switch ve VMS modelinizin neyi gerçekten sunduğunu test edin; veri sayfasında yazanla API’den dönen her zaman aynı değildir.

Katman	Metrik	Kaynak	Kontrol sıklığı
Güç	PoE port durumu, çekilen güç	Switch SNMP (POWER-ETHERNET-MIB)	1–5 dk
Fiziksel	ifOperStatus, CRC/giriş hataları	Switch SNMP (IF-MIB)	1–5 dk
Ağ	ICMP gecikme, paket kaybı	İzleme sunucusu	1 dk
Servis	RTSP/ONVIF yanıtı, NTP sapması	Sentetik kontrol, ONVIF	5–15 dk
Akış	Kare hızı, bitrate, bağlantı durumu	VMS API / sağlık modülü	1–5 dk
Kayıt	Son yazılan kayıt zamanı, boşluklar	VMS API, NVR olayları	5–15 dk
Görüntü	Tamper, odak kaybı, sahne değişimi	ONVIF olayları, VMS analitiği	Olay tabanlı
Donanım	Kamera içi sıcaklık, SD kart durumu	Kamera SNMP / üretici API	15 dk

SNMP, ONVIF olayları ve VMS API

Switch tarafında SNMP

Kamera sağlığının en güvenilir ilk göstergesi kameranın kendisi değil, bağlı olduğu switch portudur. Gücü kesilen kamera hiçbir şey raporlayamaz. Port durumu ve hata sayaçları standart IF-MIB’den, PoE algılama durumu RFC 3621 ile tanımlanan POWER-ETHERNET-MIB’den okunur. PoE ile beslenen bir portta pethPsePortDetectionStatus değeri deliveringPower(3) dışına çıktığında (örneğin searching(2), fault(4) veya otherFault(6)) kamera gücünü kaybetmiştir. SNMPv3 authPriv ile okuma:

# PoE algılama durumu (POWER-ETHERNET-MIB::pethPsePortDetectionStatus)
snmpwalk -v3 -l authPriv -u izleme -a SHA -A 'AuthParola' -x AES -X 'PrivParola' \
  10.20.0.2 1.3.6.1.2.1.105.1.1.1.6

# Port çalışma durumu (IF-MIB::ifOperStatus) ve giriş hataları (IF-MIB::ifInErrors)
snmpwalk -v3 -l authPriv -u izleme -a SHA -A 'AuthParola' -x AES -X 'PrivParola' \
  10.20.0.2 1.3.6.1.2.1.2.2.1.8
snmpwalk -v3 -l authPriv -u izleme -a SHA -A 'AuthParola' -x AES -X 'PrivParola' \
  10.20.0.2 1.3.6.1.2.1.2.2.1.14

Port başına çekilen güç çoğunlukla üreticiye özel MIB’lerdedir (Cisco’da CISCO-POWER-ETHERNET-EXT-MIB gibi). Konsolda ilk bakılacak yer de burasıdır: bir kamera periyodik olarak yeniden başlıyorsa ve çektiği güç sınıf limitine yakınsa, IR’ın gece devreye girdiği anda bütçe aşılıyor olabilir. Kamera VLAN’ındaki switch’lerde SNMP yalnız v3 ve yalnız izleme sunucusuna açık olmalı; v2c community’si “public” kalmış switch hâlâ sık görülür. Ayrıntılar için SNMPv3 authPriv yapılandırma rehberine bakın.

Kamera tarafında ONVIF olayları

ONVIF uyumlu kameralar olayları Event servisi üzerinden yayımlar. İzleme platformu CreatePullPointSubscription ile abone olur, PullMessages ile olayları çeker. Kameranın desteklediği konular (topic) GetEventProperties ile sorgulanır; görüntü kalitesiyle ilgili olanlar genellikle tns1:VideoSource ağacı altındadır (sahne değişimi, bulanık görüntü, aşırı karanlık gibi). Konu adları model ve firmware sürümüne göre değişir. Bir firmware güncellemesinden sonra olay aboneliği sessizce düşebilir; güncelleme sonrası kontrol listesine “olay akışı geliyor mu” maddesini ekleyin. Hangi profilin olay ve analitik desteği sunduğu ONVIF Profile T, G ve M karşılaştırmasında ayrıntılı; spesifikasyonlar ONVIF’in resmi sitesinde yayımlanır.

VMS API

Kurumsal VMS’lerin çoğu kamera bağlantı durumunu, kayıt durumunu ve son kayıt zamanını REST API veya SDK üzerinden verir. Akış ve kayıt katmanı için en değerli kaynak budur, çünkü “kamera erişilebilir ama kayıt yok” durumunu yalnız kaydı yapan sistem bilir. API için ayrı, yalnız okuma yetkili bir servis hesabı açın; bu hesabın canlı veya kayıtlı video izleme yetkisi olmasın. İzleme hesabı görüntü göremez.

Sentetik akış kontrolü

VMS API’si sınırlıysa RTSP akışını doğrudan test eden bir kontrol eklenir. Bu kontrol kamerada ek bir oturum açar; eski modellerde eşzamanlı oturum sınırı düşüktür ve ana akışa bağlanan bir test VMS’in bağlantısını düşürebilir. Bu yüzden alt akışta (substream) ve seyrek aralıklarla çalıştırın:

ffprobe -v error -rtsp_transport tcp -select_streams v:0 \
  -show_entries stream=codec_name,width,height,avg_frame_rate -of csv=p=0 \
  "rtsp://izleme:Parola@10.20.1.45:554/stream2"
# Beklenen çıktı örneği: h264,640,360,15/1

Çözünürlük veya kare hızı envanterdeki değerden farklıysa birisi kamera ayarını değiştirmiş olabilir. RTSP yolu (/stream2 vb.) üreticiye göre değişir; doğru yolu tahmin etmeyin, ONVIF GetStreamUri ile alın.

Görüntü kalitesi kontrolleri: tamper, odak kaybı

Görüntü katmanı en çok atlanan, olay anında da en çok can yakan katmandır. Ağ tarafında her şey yeşilken kamera işe yaramaz görüntü kaydedebilir. İzlenmesi gereken durumlar:

• Kapatma (occlusion): Lensin örtülmesi, boyanması veya önüne nesne konması.
• Görüş açısı değişimi: Darbe veya gevşeme nedeniyle kameranın dönmesi; görüntü temizdir ama yanlış alanı gösterir.
• Odak kaybı: Motorize lensli kameralarda sıcaklık değişimiyle ya da kubbe içinde yoğuşmayla bulanıklaşma.
• Aşırı karanlık: IR LED arızası veya gündüz/gece geçişinin takılı kalması.
• Donmuş görüntü: Akış geliyor ama kareler değişmiyor; bazı kodlayıcı arızalarında görülür ve bitrate grafiği düz çizgiye döner.

Kamera üzerindeki tamper algılama hızlı tepki verir, ama hassasiyeti kötü ayarlanırsa her far ışığında alarm üretir. Ekip birkaç hafta sonra bu alarmı okumayı bırakır. Tamamlayıcı yöntem, VMS’in veya küçük bir betiğin her kameradan günde birkaç kez (örneğin 10:00 ve 22:00) anlık görüntü alıp referans görüntüyle karşılaştırmasıdır. Referans görüntüyü devreye alma sırasında, kabul testinde onaylanan kadrajla kaydedin. Referans yoksa “değişti” demenin ölçüsü de yoktur.

Kayıt sürekliliği izleme

Bu katmandaki soru “kamera şu an kayıt yapıyor mu?” değil, “son 24 saatte beklenen kaydın tamamı diskte mi?” sorusudur. Üç kontrol birlikte kullanılır:

1. Son kayıt zamanı: Sürekli kayıt yapan kamerada son yazılan blok birkaç dakikadan eskiyse alarm.
2. Kayıt boşluk taraması: Her kameranın zaman çizelgesi günlük taranır, belirlenen süreden uzun boşluklar raporlanır. Olay tabanlı kayıtta boşluk normaldir; o kameralar ayrı kuralla değerlendirilir.
3. Saklama süresi kontrolü: Her kameranın en eski kaydının tarihi hedef saklama süresiyle karşılaştırılır. Disk dolduğunda eski kayıtların planlanandan erken silinmesi ancak böyle yakalanır.

Sahada sık görülen tablo şudur: bir kamerada bitrate profili yükseltilmiş, disk hesabı güncellenmemiş, NVR sessizce eski kaydı ezmeye başlamış. Kâğıt üstünde saklama hedefi 30 gün, fiilen diskte kalan çok daha az; kimse fark etmemiş. NVR’ın disk ve RAID durumu da bu katmanın parçasıdır; okuma hatası veya degrade dizi kayıt boşluklarının en yaygın kaynaklarındandır. Arıza anındaki adımlar NVR disk arızası ve RAID rebuild rehberinde anlatılıyor.

Alarm eşikleri ve eskalasyon

Kötü kurulmuş eşikler ya alarm yorgunluğu ya da sessiz arıza üretir. Aşağıdaki değerler başlangıç noktasıdır; sahada iki–dört hafta gözlemden sonra ayarlanmalı.

Durum	Önerilen tetik	Öncelik
Kritik kamerada akış yok	3 ardışık başarısız kontrol	Yüksek
Kayıt diske yazılmıyor	Son kayıt > 5 dk (sürekli kayıtta)	Yüksek
PoE fault / port down	Durum değişimi anında	Kamera önemine göre
Port CRC hataları artıyor	Sayaç artışı 15 dk boyunca sürüyor	Orta
Tamper / sahne değişimi	Olay + anlık görüntü doğrulaması	Orta–yüksek
Kare hızı düşüşü	Profil değerinin belirgin altında, 10 dk	Düşük
Saklama süresi altına düşme	Günlük kontrolde tespit	Orta

Eskalasyon için kameraları kritiklik sınıflarına ayırın: kasa, giriş kapısı, sevkiyat rampası gibi kanıt değeri yüksek noktalar birinci sınıf; genel alan kameraları ikinci sınıf. Aynı switch’e bağlı on kamera aynı anda düştüğünde on ayrı alarm değil, tek bir “switch/uplink” alarmı gelmeli. Bunun için izleme sistemine switch–port–kamera bağımlılığı tanımlanır. Bu ilişki envanterde yoksa önce kamera envanteri düzeltilmeli; bağımlılık haritası olmadan alarm bastırma kurulamaz.

Periyodik bakım pencereleri de alarm kurgusunun parçasıdır. Firmware güncellemesi veya switch değişimi sırasında ilgili kameralar planlı bakım moduna alınmazsa ekip gürültüye alışır. Gürültüye alışan ekip gerçek alarmı kaçırır.

Raporlama ve haftalık gözden geçirme

Gerçek zamanlı alarm tek başına yetmez; tekrarlayan küçük sorunlar ancak trendde görünür. Haftada bir yarım saatlik gözden geçirmede şunlara bakın:

• En çok alarm üreten kameralar ve kök nedenleri (kablo, konnektör, PoE bütçesi, firmware).
• Toplam kayıt boşluğu süresi ve etkilenen kritik kameralar.
• Açık kalan tamper ve görüş açısı bulguları; sahada düzeltilip düzeltilmediği.
• Saklama süresinin altına düşen kayıt cihazları ve disk doluluk eğilimi.
• Eşiklerden kaynaklanan yanlış alarmlar ve yapılan ayar değişiklikleri.

Aynı kamera her hafta listedeyse sorun alarm değil, sahadadır. Çoğu zaman oksitlenmiş bir RJ45 ya da dış ortamda nem almış bir bağlantı kutusu çıkar. Otomatik izleme sahadaki elle kontrolün yerini tutmaz; lens temizliği, montaj sıkılığı ve kabin kontrolü için periyodik bakım kontrol listesi kullanılmaya devam eder. İzleme verisinin hizmet sözleşmesindeki erişilebilirlik ve kayıt sürekliliği metriklerine nasıl bağlanacağı yönetilen kamera hizmetinde SLA tasarımı yazısının konusu.

Katmanlı izlemeyi mevcut ağ izleme altyapınızla birleştirmek için kamera ağ izleme ve arıza alarmı hizmet kapsamına göz atabilirsiniz.

Sık sorulan sorular

Kameranın ping’e yanıt vermesi neden yeterli değildir?

Ping yalnızca kameranın ağ arayüzünün çalıştığını gösterir. Akışın VMS’e ulaşıp ulaşmadığı, kaydın diske yazılıp yazılmadığı ve görüntünün kapatılmış, bulanık veya yanlış yöne çevrilmiş olup olmadığı ping ile anlaşılmaz.

PoE arızasını kamera tarafından mı switch tarafından mı izlemek gerekir?

Switch tarafından. Gücü kesilen kamera hiçbir veri gönderemez; switch ise POWER-ETHERNET-MIB üzerinden port algılama durumunu ve hata durumunu bildirmeye devam eder.

Tamper alarmı neden çok yanlış alarm üretir?

Kameradaki tamper algılama genellikle ani parlaklık veya sahne değişimine tepki verir; far ışığı, gündüz-gece geçişi ve aydınlatma değişimleri onu tetikler. Hassasiyeti sahaya göre ayarlayın ve alarmı referans görüntüyle karşılaştırılan anlık görüntüyle doğrulayın.

Kayıt boşlukları ne sıklıkla kontrol edilmelidir?

Sürekli kayıt yapan kritik kameralarda son kayıt zamanı birkaç dakikalık aralıklarla, tüm kameralar için zaman çizelgesi boşluk taraması günlük yapılmalı. En eski kaydın tarihi de düzenli olarak saklama hedefiyle karşılaştırılmalı.