Tek noktadan izleme yalan söyler
Bir yayını tek yerden ölçüyorsanız, ölçtüğünüz şey yayının sağlığı değil; o noktaya giden yolun sağlığı. Aradaki farkı nasıl ayırt edeceğinizi ve oydaşmaya dayalı alarmın nasıl kurulduğunu anlatıyoruz.
Yayın operasyonunda iki senaryo vardır ve ikisi de aynı kök nedenden çıkar.
Birincisi: Gece 03:14'te alarm çalar. Telefonla bakarsınız, yayın gayet iyi akıyor. Ertesi sabah "yine yanlış alarm" diye kaydedilir ve o kural biraz daha gevşetilir.
İkincisi: İzleyiciler şikâyet eder, sosyal medyada "yayın gitti" yazarlar. Panelinize bakarsınız — her şey yeşil.
İki durum da aynı yapısal körlükten kaynaklanır: tek bir noktadan ölçüm yapıyorsunuz ve o ölçüm, "yayın bozuk" ile "benim yayına giden yolum bozuk" arasındaki farkı göremiyor.
Tek probe neyi göremez
Bir probe, bulunduğu yerden gördüğünü ölçer. Bu bariz görünür ama sonuçları çoğu ekibin hesaba katmadığı kadar geniştir:
- Probe'un kendi ağı. Probe'un bağlı olduğu hat paket kaybediyorsa, sağlıklı bir yayında continuity hatası ve segment gecikmesi görürsünüz. Ölçüm doğrudur; yorum yanlıştır.
- O bölgedeki CDN uç sunucusu. Multi-CDN veya çok bölgeli dağıtımda probe'unuza hizmet veren uç, bayat manifest servis ediyor olabilirken diğer bölgeler tertemizdir. Yayın "bozuk" değildir; bir uç bozuktur.
- DNS ve yönlendirme. Aynı alan adı farklı bölgelerde farklı IP'lere çözülür. Probe'unuzun gördüğü sunucu, izleyicilerinizin çoğunun gittiği sunucu olmayabilir.
- Coğrafi kısıt ve trafik yönetimi. Bazı akışlar bölgeye göre farklı davranır; tek noktadan bunu fark etmezsiniz.
Ortak nokta şu: tek probe size "bir sorun var" diyebilir, ama "sorun nerede" diyemez. O cevabı vermek için karşılaştıracak ikinci bir bakış açısı gerekir.
Oydaşma: alarmı kim çalar?
Çözüm, aynı yayını birden fazla noktadan ölçüp alarmı tek bir noktanın gördüğüne değil, noktaların üzerinde anlaştığı şeye bağlamaktır. Kullandığımız kural şu:
| Durum | Yorum | Alarm |
|---|---|---|
| Hiçbir nokta yayına erişemiyor | Yayın gerçekten düştü | stream_down |
| Bazıları erişiyor, bazıları erişemiyor | Erişemeyen noktanın yolu/ağı bozuk | probe_unreachable |
| Hepsi erişiyor, ölçümler ayrışıyor | Dağıtım tarafında bölgesel bir fark var | ayrışma (isteğe bağlı) |
| Hepsi erişiyor, ölçümler tutarlı | Sağlıklı | — |
Bu tablonun ikinci satırı, gece 03:14 alarmını ortadan kaldıran satırdır. Tek probe'lu bir kurulumda o satır yoktur; her erişim sorunu "yayın düştü" diye okunur.
Üçüncü satır ise çoğu ekibin hiç görmediği bilgidir: yayın ayakta, ama bir bölgede belirgin biçimde daha kötü. Tek noktadan bakarken bu bilgi var olmaz — çünkü kıyaslayacak bir şey yoktur.
Kaç nokta yeterli?
Pratikte cevap ikiden fazla, ve nedeni oy matematiğidir.
- Tek nokta: "sorun var" der, "nerede" diyemez.
- İki nokta: anlaşmazlığı tespit eder ama çözemez. İkisi farklı şey söylediğinde hangisinin haklı olduğunu bilemezsiniz.
- Üç nokta: çoğunluk oluşur. İkisi erişiyor biri erişemiyorsa, sorunun o tek noktada olduğu makul bir sonuçtur.
Buradaki itiraz genelde maliyet olur: "üç kat ölçüm, üç kat kaynak." Bu doğru değil — çünkü her noktanın aynı derinlikte ölçüm yapmasına gerek yok.
İki rol: tam ölçen ve yalnız bakan
Ölçümün pahalı kısmı erişilebilirlik değil, çözümlemedir: segment indirme, kare çıkarma, donma/siyah/sessizlik analizi, SCTE-35 takibi. İkinci bir görüş almak için bunların tekrarlanması gerekmez. Bu yüzden noktaları iki role ayırıyoruz:
| Rol | Ne yapar | Maliyeti |
|---|---|---|
| primary | Tam ölçüm: segment, QoE, thumbnail, transport, SCTE-35. Grafikleri ve KPI'ı besleyen budur. Yayın başına tek. | Yüksek |
| watcher | Yalnız erişilebilirlik. Oydaşmada oy kullanır, ölçüm derinliği yoktur. | Çok düşük |
Yani üç bakış açısı için üç tam ölçüm gerekmez: bir primary + iki watcher, oy matematiğini kurar ve maliyetin çok küçük bir kısmını ekler. Yayın başına primary'nin tek olması da bilinçlidir — iki farklı nokta aynı grafiği beslerse, hangi sayının "gerçek" olduğu tartışması başlar.
Kurarken düştüğümüz iki tuzak
Bu mimariyi canlıya alırken öğrendiğimiz, dokümantasyonda yazmayan iki şey:
1. Oydaşmayı yanlış seviyede değerlendirmek hayalet alarm üretir. Erişilemezliği her probe için ayrı ayrı değerlendirirseniz, tek bir noktanın anlık sorunu yayın seviyesinde bir olaya dönüşür. Değerlendirmenin yayın seviyesinde yapılması gerekir: önce "kaç nokta erişebiliyor" sorusu cevaplanır, alarm türü ondan sonra seçilir. Sıralamayı ters kurarsanız, çok noktalı izleme alarm sayısını azaltmak yerine artırır — yani tam tersini yapar.
2. Devredilemeyen görevler ortalıkta kalır. Bir noktayı devre dışı bıraktığınızda ona atanmış watcher görevi başka bir yere devredilemiyorsa, o görev silinmelidir. Aksi hâlde arayüzde "+2 nokta" yazar ama o noktalar aslında hiçbir şey ölçmez. Ölü bir ölçüm noktası, hiç olmayan noktadan daha tehlikelidir; çünkü ona güvenirsiniz.
Noktaları nereye koymalı?
Üç farklı bakış açısı, üç farklı soruyu cevaplar:
- Kendi ağınızın içine (headend yakını). "Kaynak sağlıklı mı?" Buradaki bir sorun sizin sorumluluğunuzdadır ve dışarı çıkmadan yakalanır.
- Dağıtımın çıkışında (CDN/uç bölgesi). "Dağıtıcı işini yapıyor mu?" Tedarikçiyle yapılan SLA görüşmesinin dayanağı bu noktadır.
- İzleyiciyi temsil eden bir ağda (yerel ISP). "İzleyici gerçekte ne alıyor?" Şikâyetlerin sizin tarafınızda mı, ISP tarafında mı olduğunu ayırt eden nokta budur.
Bu üçlü, "sorun kimde" sorusunun çoğu hâlini kapsar. Aynı anda üçünde de aynı belirti varsa yukarı bakarsınız; yalnız üçüncüsünde varsa aşağı.
Dürüst bir sınır
Probe'lar, bulundukları yerden ölçen sentetik izleyicilerdir. Gerçek izleyici değildirler. Cihaz çeşitliliği, oynatıcı davranışı, ev içi Wi-Fi, uygulama hataları — bunları probe görmez. Çok noktalı izleme, dağıtım zincirindeki sorunları izole etmek için tasarlanmıştır; izleyici tarafındaki deneyimi ölçmek için oynatıcıdan gelen veriye (client-side telemetri) ihtiyaç vardır. İkisi birbirinin yerine geçmez, birbirini tamamlar.
Yine de şu pratik gerçek değişmez: yayınınızı tek bir yerden izliyorsanız, ölçtüğünüz şeyin ne olduğundan emin olamazsınız. İkinci bir bakış açısı eklemenin maliyeti, bir gecelik yanlış alarmın maliyetinden düşüktür.