Cem Kemal Erbaş Network, Siber Güvenlik ve Teknik Rehberler
SNMP polling hâlâ iş görür; ama gecikmeli, ölçeklemesi zor ve çoğu zaman “olay olduktan sonra” resim verir. Streaming Telemetry (gNMI / Model-Driven Telemetry) ise cihazın YANG modelleri üzerinden push mantığıyla, yüksek frekansta ve yapılandırılmış formatta (JSON/GPB) veri gönderir. Sonuç: CPU spike, forwarding sorunları, hot interface, queue/buffer büyümesi gibi anormallikler dakikalar yerine saniyeler içinde yakalanır.
📝 Neden önemli?
- Polling gecikmesi yok: “10 dakikada bir” yerine 5–10 sn gibi periyotlarla trendi yakalarsın.
- Yapılandırılmış veri: Regex ile log kazımak yerine YANG path’leriyle temiz alanlar.
- Daha iyi anomali tespiti: Mikro patlamalar, kısa süreli paket kaybı/queue şişmesi gibi “kaçan” anlar yakalanır.
- Ölçeklenebilir operasyon: Collector/TSDB ile merkezi ölçüm, alarm, kapasite planlama.
🧩 Mimari (kısa)
Network cihazı (YANG telemetry) → gRPC/gNMI collector → TSDB (InfluxDB/Prometheus/ClickHouse vb.) → Grafana → Alerting + Runbook
⚙️ Hızlı uygulanabilir örnek (IOS-XE — Model-Driven Telemetry)
⚠️ Üretimde: TLS/mTLS, management VRF, source-interface, rate-limit / sampling, ACL ve canary rollout mutlaka planlanmalı. Aşağıdaki komutlar örnektir; YANG path’leri ve komut sözdizimi sürüm/model bazında değişebilir.
1) Collector (server) tanımı
configure terminal
telemetry model-driven
server-group COLLECTORS
destination 10.10.10.100 port 57400
exit
exit
2) Sensor-group (neyi izleyeceğiz?)
En kritik kural: “Her şeyi tek sensöre koyma.” Büyük path’leri böl, amaca göre sensör oluştur.
configure terminal
telemetry model-driven
sensor-group SG_INTERFACES
sensor-path Cisco-IOS-XE-interfaces-oper:interfaces/interface
exit
exit
3) Subscription (push ayarı)
- stream:
yang-push - update-policy: periyodik (ör. 10s)
- source-interface: telemetri trafiği için sabit ve yönetilebilir kaynak IP
configure terminal
telemetry model-driven
subscription SUB_IFACE
sensor-group-id SG_INTERFACES
stream yang-push
update-policy periodic 10000 ! ms: 10.000ms = 10s
source-interface Loopback0
server-group COLLECTORS
exit
exit
✅ Doğrulama (en hızlı kontroller)
show telemetry model-driven subscription all
show telemetry model-driven sensor-group
show running-config | section telemetry
🧰 Collector & Araç Zinciri (pratik öneriler)
Hızlı test
gnmic(gNMI CLI) /pygnmiile “veri geliyor mu?” doğrula
Görselleştirme
- Telegraf → InfluxDB → Grafana (çok pratik başlangıç)
- Prometheus için exporter/translate katmanı (telemetry → metrics)
Ölçek
gnmi-proxyveya “stream → Kafka” mimarisiyle çok cihazda fan-out- Collector tarafında buffer/backpressure kontrolü (burst’lerde düşmemesi için)
✅ En iyi uygulamalar (operasyonel kurallar)
1) Management VRF + source-interface
- Telemetry trafiği “data plane” ile karışmasın; mgmt VRF üzerinden taşı.
- Source IP sabit olursa firewall/ACL/policy yönetimi kolaylaşır.
2) TLS & Sertifika yönetimi
- gRPC/gNMI için mTLS kullan (client + server doğrulama).
- Sertifika yenilemesini otomatikleştir (kurum PKI / ACME benzeri).
3) Sampling (update-policy) — “her metriğe aynı hız” yok
Önerilen başlangıç (genel):
- Interface counters: 10s
- CPU/Memory: 5–10s
- Routing state / neighbor: 10–30s
- Flow/advanced detay: 30s+ (yükü düşün)
4) Sensor-group tasarımı
- “Devasa path” tek subscription’da olmasın.
- Network operasyonuna göre böl:
interfaces,system,routing,qos/queuesgibi.
5) Backpressure & batching
- Collector burst kaldıramıyorsa: throttling/sampling artır.
- Cihaz CPU’sunu tüketmeyecek dengeyi tuttur.
6) Verify & Canary
- 1–2 cihazla başla, KPI’ları ölç (CPU, bandwidth, collector drop).
- Sonra kademeli rollout.
7) Storage & Retention
- Yüksek frekans veri = TSDB maliyeti.
- Kısa dönem: yüksek çözünürlük (raw)
- Uzun dönem: downsample/rollup (özet)
Cem Kemal Erbaş sitesinden daha fazla şey keşfedin
Subscribe to get the latest posts sent to your email.
