SNMP untuk Fleet CCTV: Memantau Kamera Sebelum Rekaman Hilang

SNMP untuk Fleet CCTV: Memantau Kamera Sebelum Rekaman Hilang

Kamera yang mati enam jam, baru ketahuan justru saat rekamannya benar-benar dibutuhkan — itu mode kegagalan terburuk dalam deployment video analytics. Bukan model yang jelek. Bukan deteksi yang terlewat.

Pipeline analytics-nya baik-baik saja. Dashboard-nya terlihat normal. Tidak ada yang memantau satu sinyal yang sebenarnya bisa menangkap masalah ini: apakah perangkatnya sendiri masih hidup.

Saya memantau fleet kamera pakai SNMP justru karena alasan ini. Protokol lama yang tidak menarik, dan itu justru intinya. Setiap managed switch, PoE injector, NVR, dan IP camera sudah bicara SNMP secara default, jadi ini satu kanal yang tidak perlu dinegosiasikan per vendor.

SNMP itu lapisan yang membosankan, dan justru karena itu ia bekerja

SNMP (Simple Network Management Protocol) adalah protokol request/response untuk menanyakan kondisi sebuah perangkat ke dirinya sendiri. Apakah dia hidup, sudah berapa lama hidup, apa yang terjadi di interface jaringannya.

Setiap nilai berada di sebuah OID (object identifier), alamat berformat titik menuju MIB perangkat — katalog data yang tersedia. Tiga OID ini mencakup sebagian besar kebutuhan monitoring harian fleet kamera:

• 1.3.6.1.2.1.1.3.0 — sysUpTime, waktu sejak perangkat terakhir kali reinitialize, dalam satuan per seratus detik. Kamera yang uptime-nya baru saja kembali ke nol berarti baru reboot, entah ada yang melaporkannya atau tidak.
• 1.3.6.1.2.1.1.1.0 — sysDescr, string hardware dan firmware yang dilaporkan sendiri oleh vendor, berguna untuk memastikan perangkat mana yang sebenarnya sedang di-poll.
• 1.3.6.1.2.1.2.2.1.8 — ifOperStatus per interface, apakah sebuah link secara administratif dan operasional up. Di PoE switch, ini memberitahu port mana yang baru saja drop, sering kali sebelum kameranya sendiri berhenti merespons.

Semua ini tidak butuh tooling khusus vendor. Subtree MIB-2-nya sama saja antara kamera seharga $40 dan switch seharga $4.000.

Polling dari backend Node

Untuk backend Node yang saya bangun di deployment seperti ini, saya pakai net-snmp, implementasi JavaScript untuk SNMP v1, v2c, dan v3 yang dirilis dengan lisensi MIT. Package ini memberi objek session dengan get(), getBulk(), walk(), dan subtree(), plus dukungan trap dan inform kalau perangkatnya mampu mendorong alert sendiri, bukannya menunggu di-poll — ditanyai satu per satu secara berkala.

Poll kesehatan minimal kira-kira begini:

const snmp = require("net-snmp");

const session = snmp.createSession(camera.ip, "public", { version: snmp.Version2c });

session.get(["1.3.6.1.2.1.1.3.0"], (error, varbinds) => {
  if (error) {
    markUnreachable(camera.id);
  } else {
    recordUptime(camera.id, varbinds[0].value);
  }
  session.close();
});

Jalankan ini ke setiap perangkat di VLAN kamera setiap 60 detik. Anda langsung punya baseline reachability dan uptime untuk seluruh fleet, termasuk switch-nya, tanpa menyentuh SDK vendor sama sekali. getBulk() menarik seluruh interface table dalam satu round trip saat menyusuri counter di switch berpuluh-puluh port. Ini mulai terasa penting begitu polling per-OID makan waktu lebih lama dari interval polling-nya sendiri.

Yang tidak bisa dilihat SNMP

Ini bagian yang sering bikin orang salah kira: kamera bisa menjawab SNMP dengan benar, uptime naik terus, interface up, ping sehat. Sementara itu feed videonya sebenarnya sudah beku. Bayangkan mobil dengan mesin menyala dan jarum speedometer bergerak normal, tapi kameranya sendiri mati sejak lama. Dashboard bilang semua sehat, padahal yang sehat cuma mesinnya.

Chip yang menjalankan network stack dan pipeline yang meng-encode frame adalah subsistem berbeda di hardware kamera murah. Fault di encoder atau sensor tidak otomatis ikut menjatuhkan network stack-nya. Saya pernah menemukan kamera yang session SNMP-nya sehat selama berjam-jam, padahal stream RTSP-nya sudah berhenti menghasilkan frame baru sejak lama.

Cek kesehatan RTSP yang benar berarti melampaui sekadar "apakah koneksinya terbuka." Request OPTIONS biasa ke URL RTSP tidak bisa diandalkan untuk ini. Sebagian kamera merespons normal padahal sebenarnya macet. Sebagian lagi mengembalikan error pada stream yang justru sehat.

Yang benar-benar bekerja adalah frame-age watchdog: buka stream-nya, lacak timestamp frame terakhir yang benar-benar berhasil di-decode, dan alert begitu usia frame itu melewati ambang batas. Ambang batas ini biasanya 30 sampai 60 detik, cukup longgar supaya tidak banjir alert gara-gara hiccup bitrate biasa. ffprobe yang dijalankan berkala ke tiap URL stream, atau proses consumer kecil yang pakai binding RTSP/FFmpeg, sama-sama bisa memberi timestamp itu. Tidak perlu merekam atau menampilkan videonya.

SNMP dan watchdog RTSP menjawab dua pertanyaan yang berbeda, dan fleet dashboard butuh keduanya:

Device-down dan stream-stale adalah dua kelas kegagalan berbeda. Yang satu biasanya masalah jaringan atau daya. Yang satu lagi biasanya fault di sensor, encoder, atau kartu penyimpanan pada perangkat yang secara jaringan masih sepenuhnya bisa dijangkau. Menggabungkan keduanya jadi satu lampu status menghilangkan informasi soal masalah mana yang sebenarnya sedang dihadapi.

Desain alert: outage yang sama, biaya yang sangat berbeda

Kamera mati lima menit jam 3 pagi di area parkir yang sepi adalah noise hampir setiap malam. Port PoE sempat blip, switch reboot, lalu kembali normal. Gap lima menit yang sama pada satu-satunya kamera yang mengawasi pintu masuk itu beda cerita. Baru ketahuan tiga hari kemudian saat menarik rekaman untuk tinjauan insiden, itu kegagalan yang benar-benar berdampak.

Polling SNMP saja tidak bisa membedakan keduanya; ia cuma melaporkan "bisa dijangkau" atau "tidak bisa." Desain alert harus membawa pertimbangan itu:

• Debounce flap sesaat. Syaratkan kegagalan bertahan lewat dua atau tiga siklus polling sebelum mem-page siapa pun, atau setiap switch reboot akan jadi alert jam 3 pagi.
• Beri bobot kamera berdasarkan area yang diawasi, bukan sekadar jumlah perangkat. Kamera area parkir dengan gap lima menit cukup jadi log line; kamera pintu masuk atau kasir dengan gap yang sama harus jadi page.
• Lacak durasi downtime per kamera, bukan cuma status sesaat. Kamera yang flapping tiap dua puluh menit harus tetap muncul di laporan mingguan, meskipun statusnya "up" tiap kali dicek.

Dasar-dasar fleet dashboard

Dashboard-nya sendiri tidak perlu rumit. Tabel berisi kamera, respons SNMP terakhir, uptime, timestamp frame bagus terakhir, dan status alert saat ini sudah cukup. Tabel itu menjawab pertanyaan operasional — apa yang sedang down sekarang — untuk fleet ukuran apa pun yang pernah saya tangani.

Kedua sinyal ini masuk ke status store yang sama dan terbaca kembali sebagai satu baris per perangkat. Alur menyalurkan jenis ingestion seperti ini ke dashboard live mengikuti pola yang sama dengan yang saya bahas di panduan backend IoT. Yang benar-benar menangkap insiden bukan UI yang lebih canggih. Yang menangkap insiden adalah memastikan kedua sinyal ini sudah terkumpul sebelum hari saat seseorang perlu menjawab "apakah kamera ini sebenarnya masih berfungsi."

Ini semua tidak menggantikan hardening dan konfigurasi kamera yang benar sejak awal — lihat checklist hardening firmware untuk apa saja yang harus beres sebelum kamera live. Monitoring memberi tahu Anda saat perangkat yang tadinya sudah dikonfigurasi benar berhenti berperilaku seperti itu. Kamera yang sejak awal tidak dikonfigurasi dengan benar akan gagal dengan cara yang tidak tertangkap oleh polling apa pun.

Intinya

Kamera mati murah untuk dideteksi. Mahal kalau baru ketahuan belakangan. SNMP memberi reachability dan uptime secara gratis, di seluruh perangkat di jaringan, memakai protokol yang sudah diimplementasikan setiap vendor.

Tapi ia tidak akan memberi tahu kalau stream-nya beku — itu butuh cek frame-age terhadap feed RTSP yang sebenarnya. Jalankan keduanya, alert-kan secara terpisah. Kegagalan yang dulu baru muncul saat tinjauan insiden sekarang muncul di dashboard dalam hitungan menit sejak kejadiannya.