Observability Nedir? Tablo Meraklıları İçin Sade Rehber
Summary
Observability nedir? Bir sistemin ne yaptığını ve neden yaptığını, ürettiği loglar, metrikler ve trace'lerle anlayabilme becerisidir. Monitoring önceden tanımladığınız sorunları yakalar, observability ise öngörmediklerinizi araştırmanıza yardım eder. Bu rehber farkı tablo diliyle anlatır, hata oranı ve yüzdelik değerler için Sheets ve Excel formüllerini gösterir, ekiplerin kullandığı araçları ve maliyetlerini karşılaştırır, son olarak da pazartesi günü uygulayabileceğiniz dört basit adımı paylaşır. Formüllerde Excel 2016 ile Excel 365 arasındaki farklar da belirtilir.
Observability nedir? Bir sistemin ne yaptığını ve neden yaptığını, yalnızca ürettiği verilerle anlayabilme becerisidir. Bu veriler üç temel kaynaktan gelir: loglar, metrikler ve trace'ler. Monitoring bir şeyin bozulduğunu söyler. Observability ise bir sonraki soruyu sormanıza izin verir: nerede, kim için ve ne zamandan beri? Tablolarla çalışıyorsanız bunu zaten küçük ölçekte yapıyorsunuz. Bir sayı tuhaf göründüğünde, onu kaynak satırına kadar geri izlersiniz.
Bir dakikada özet: tablo meraklıları için
Aylık gelir tablonuzdaki toplamın yanlış göründüğünü düşünün. "Toplam sapmış" diyen bir pano monitoring'dir. Bölgeye, güne ve ürüne göre filtreleyip 400 satırı iki katına çıkaran tek bir içe aktarımı bulabiliyorsanız, o observability'dir.
Yazılım ekipleri canlı sistemlerde aynı duvara çarpar. Ödeme sayfası yavaşlar, bir uyarı çalar. Artık birinin hangi servisin, hangi müşteri grubunun ve hangi yayının sorunu çıkardığını bulması gerekir. Bunu mümkün kılan veriye telemetri denir. Bu telemetriyi ne kadar iyi kullanabildiğiniz, insanların observability dediği şeydir.
Biscuit'in de buna benzer bir yöntemi var. Topun kaybolduğunu söylemenize gerek yok. Topu en son nerede gördüğünü bulmak istiyor.
Monitoring ile observability: bilinen sorunlar ile sürprizler
Monitoring, önceden izlemeye karar verdiğiniz şeyleri izler. CPU kullanımı yüzde 90'ı geçtiğinde, hata oranı yüzde 2'yi aştığında, bir sayfa cevap vermeyi kestiğinde. Kuralı siz yazarsınız, kural bozulunca araç alarm verir.
Observability ise için kural yazmadığınız sorunlar içindir. OpenTelemetry projesi bunu, bir sistemi iç yapısını bilmeden dışarıdan anlama yolu olarak tanımlar. Bu yaklaşım, "bilmediğimiz bilinmeyenler" için işe yarar.
İkisinin birbirinin yerini aldığı fikrini bırakın. Monitoring duman alarmıdır. Observability ise sonradan açıp baktığınız kat planı ve kamera kaydıdır. İkisine de ihtiyacınız var.
Pratik bir ipucu: yeni bir alarm eklemeden önce, o alarmın son üç ayda kaç kez çalacağını tahmin edin. Cevap "her gün" ise, bu muhtemelen bir uyarı değil, gürültüdür. Gürültüye alışan ekipler, gerçek uyarıyı da görmezden gelmeye başlar.
Loglar, metrikler ve trace'ler: üç ham malzeme
Neredeyse her açıklama aynı üç sinyale varır. Her birini tablo diliyle açıklayalım.
Loglar tek tek olaylara ait zaman damgalı mesajlardır. Tabloda bu, olay başına bir satırdır: zaman, kullanıcı, işlem, sonuç. En fazla ayrıntıyı tutarlar ve en çok yer kaplarlar.
Metrikler zaman içinde toplanan sayılardır: hata oranı, dakikadaki istek sayısı, kullanılan bellek. Tabloda bu, özet sekmenizdir. Saklaması ucuz, grafiğe dökmesi kolaydır ama hangi tek isteğin başarısız olduğunu söyleyemez.
Trace'ler bir isteğin birden çok servis içinden geçerken izlediği yolu, her adımda ne kadar zaman harcadığıyla birlikte gösterir. Tabloda bu, bir sipariş numarasını beş sekmede takip edip her birinde ne kadar beklediğini not etmeniz gibidir.
Kısa özet şöyle: metrikler bir şeyin yanlış olduğunu söyler, trace'ler kabaca nerede olduğunu, loglar ise ayrıntıyı. Gerçek bir hücrede nasıl göründüğüne bakalım.
5.000 log satırınız var: Sheets'te adım adım bir örnek
Diyelim ki bir uygulamanın 5.000 satırlık logunu Google Sheets'e aktardınız. A sütununda zaman damgası, B'de servis adı, C'de durum kodu, D'de milisaniye cinsinden yanıt süresi var. Aksi belirtilmedikçe formüller hem Excel'de hem Sheets'te çalışır.
Önce klasik bir metrik olan hata oranı:
=COUNTIF(C2:C5001, ">=500") / COUNTA(C2:C5001)Aralık C2:C5001, yani durum kodlarıdır.
">=500"ölçütü her sunucu hatasını sayar.COUNTAile bölmek tüm isteklerin oranını verir. Hücreyi yüzde biçimine getirin.
Bu monitoring: tek sayı, tek eşik. Şimdi observability kısmına geçelim. Hatadan sorumlu servis hangisi?
=QUERY(A1:D5001, "select B, count(C) where C >= 500 group by B order by count(C) desc", 1)Bu formül yalnızca Sheets'te çalışır, çünkü QUERY'nin Excel'de karşılığı yoktur. Argümanları şöyle okuyun:
Veri A1:D5001 aralığında, başlıklar dahil.
Metin, SQL benzeri kısa bir sorgu: servis başına hataları say, en çoktan en aza sırala.
Sondaki
1, bir başlık satırı olduğunu söyler.
Excel 365'te aynı sonuca farklı bir tarifle ulaşırsınız:
=LET(s, FILTER(B2:B5001, C2:C5001>=500), u, UNIQUE(s), HSTACK(u, COUNTIF(s, u)))Bu formül için Excel 365 ya da 2021 gerekir, çünkü FILTER, UNIQUE ve HSTACK Excel 2016'da yoktur. Türkçe arayüzlü Excel'de aynı fonksiyonlar Türkçe adlarıyla girilir (örneğin COUNTIF yerine EĞERSAY). Eski sürümler için pivot tablo daha uygun olur.
Yavaş istekler için ortalamadan daha dürüst olan 95. yüzdelik değer:
=PERCENTILE(D2:D5001, 0.95)Ortalama yanıt süresi 180 ms ama 95. yüzdelik 2.400 ms ise, her yirmi kullanıcıdan biri kötü bir deneyim yaşıyor demektir. Ortalamalar bunu gizler. Observability araçlarının sizi kurtarmaya çalıştığı tuzak tam da budur.
Bu üç formül birlikte okunduğunda küçük bir hikaye anlatır: önce sorunun var olduğunu görürsünüz, sonra hangi servisten geldiğini bulursunuz, en son da kullanıcıların ne kadar etkilendiğini ölçersiniz. Gerçek bir sistemde bu sırayla ilerlemek, log hacmi büyüse bile sizi boğmaz.
Formülü unutan sizseniz, Biscuit onu zaten getirdi. Formula.dog düz dille anlattığınız bir işlemi bu tarz bir formüle çevirir.
Olağan bir iş gününde observability nerede karşınıza çıkar
Sunucu işletmek zorunda değilsiniz. Bu düşüncenin ilk adımı küçüktür. Bir raporu hazırlarken aynı iki soruyu sorun: "Bu rakam nereden geliyor?" ve "Bu rakamı parçalara ayırabilir miyim?" İkisine de evet diyebiliyorsanız, observability'nin temel hareketini zaten yapıyorsunuz. Hayır diyorsanız, eksik olan çoğu zaman bir ID sütunudur, daha fazla araç ya da daha karmaşık bir formül değil. Pratikte bir ekip genellikle dört soruyla başlar: hangi servis en çok hata veriyor, hangi işlem en yavaş, bu hafta ne değişti ve hangi müşteri etkilendi.
Bir destek ekibi lideri "Salı günü biletler neden iki katına çıktı?" diye sorduğunda, observability düşüncesini kullanıyor demektir. Bir finans analisti bir sapmayı tek bir tedarikçi faturasına kadar takip ettiğinde, ya da bir operasyon çalışanı gece içe aktarımın bir dosyayı sessizce atladığını fark ettiğinde de öyle.
Yazılımda aynı sorular dağıtık sistemler yüzünden daha keskinleşir. Bir düğmeye tıklamak API ağ geçidine, kimlik doğrulama servisine, veritabanına ve bir ödeme sağlayıcısına dokunabilir. Hata olduğunda gördüğünüz mesaj çoğu zaman sorunun başladığı yer değildir. Bir trace tüm zinciri gösterir, yavaş ya da bozuk halka vurgulanır ve kimse tahmin yürütmek zorunda kalmaz.
Sık geçen üç terimi sade bir dille açıklayalım:
Instrumentation telemetri üreten kodu eklemektir. Daha önce hiç zaman damgası ya da ID sütunu olmayan bir rapora bunları eklemeye benzer.
Cardinality bir alanın alabileceği farklı değerlerin sayısıdır. Bölgenin kardinalitesi düşüktür, kullanıcı ID'si ise çok yüksektir. Yüksek kardinaliteli alanlar en keskin soruların cevabını verir ama saklaması en pahalı olanlardır.
SLO (hizmet seviyesi hedefi) kendinize koyduğunuz bir hedeftir, örneğin "ödemelerin yüzde 99,5'i iki saniyenin altında tamamlanır". Belirsiz bir endişeyi izleyebileceğiniz bir sayıya çevirir.
Dashboard yığını neden observability değildir
Burası satıcıların hoşuna gitmeyecek bir görüş: üç sinyale birden sahip olmak observability'ye sahip olduğunuz anlamına gelmez. Metrikler bir araçta, loglar başka bir araçta, trace'ler üçüncü bir araçta duruyorsa, gece 02.00'de biri bunları elle hizalamak zorunda kalır. Ortak bir ID sütunu olmayan üç çalışma kitabına benzer.
Test basit: beklenmedik bir şey bozulduğunda, yeni kod yayınlamadan verinize yeni bir soru sorabiliyor musunuz? Cevap "loglama eklememiz ve yeniden yayınlamamız gerekir" ise, elinizde yalnızca ekstra adımlı bir monitoring var demektir.
Pratikte iki şey fark yaratır:
Her olayda bağlam. Her log satırı bir istek ID'si, servis adı ve sürüm taşır, böylece sonradan gruplayıp filtreleyebilirsiniz. Her dışa aktarımda olmasını isteyeceğiniz ID sütunu budur.
Ayrıntının yeterince uzun tutulması. Cevapların saklı olduğu yer yüksek kardinaliteli veridir: kullanıcı ID'leri, sipariş ID'leri. Fatura da tam burada şişer.
Gerçekte kullanılan araçlar ve her birinin maliyeti
Fikri anlamak için bir şey satın almanız gerekmez, ama pazarı bilmek faydalıdır.
OpenTelemetry telemetri üretmek için açık bir standarttır. Verileri saklamaz ya da göstermez. Bir kez enstrümante edersiniz, veriyi istediğiniz yere gönderirsiniz.
Grafana Cloud açık standartlar üzerine kuruludur. Ayda 10.000 aktif metrik serisi ve her biri için 50 GB log, trace ve profil içeren ücretsiz bir katmanı vardır. Açık kaynak yığını kendiniz de barındırabilirsiniz. Bunun bedeli, Prometheus, Loki ve Tempo'yu kendiniz birleştirmektir.
Datadog hazır paket seçenektir: ajanı kurun, dakikalar içinde çalışan panolar elde edin, altyapı, APM ve loglar tek yerde olsun. Yakalaması faturalandırmada. Sunucu başına fiyatlandırma (yalnızca altyapı için ayda yaklaşık $15), buna loglar ve özel metrikler için ayrı ücretler eklenince, yaklaşık 50 sunucudan sonra hızla tırmanabilir. Kalıcı bir ücretsiz katmanı yoktur.
New Relic fiyat açısından ortada yer alır: ayda 100 GB veri alımı ücretsiz, sonrası GB başına $0,40, bir tam platform kullanıcısı dahil.
Buna değer, eğer küçük bir platform ekibiniz varsa ve altyapınızın altyapısını işletmek istemiyorsanız. Vazgeçin, eğer iki sunucunuz ve bir geliştiriciniz varsa. İyi bir log formatı ve yukarıdaki formüller sizi şaşırtıcı derecede ileri götürür.
Tekniker değilseniz pazartesi ne yapmalısınız
Hiç trace'e dokunmayabilirsiniz. Ama observability düşüncesi, sayı raporlayarak geçinen herkese iyi uyar.
Her dışa aktarıma bir ID ekleyin. Birleştirebileceğiniz bir sütun, en akıllı formülden daha değerlidir.
Ham satırları saklayın. Ayrıntı sekmesinin üzerine değer yapıştırmayın. Özetler metriktir, ham satırlar logdur.
"Normal"in ne olduğunu yazın. Hiç tanımlamadığınız bir eşik asla tetiklenmez.
Üçüncü soruyu sorun. "Gelir düştü" bir uyarıdır. "Nerede düştü?" bir metriktir. "Hangi satırlar yüzünden düştü?" ise observability'dir.
Bunları yaparsanız, tablonuzdaki bir sonraki tuhaf toplam bir öğleden sonra yerine on dakikada açıklanır.
Bu dört alışkanlığın hiçbiri bir yazılım lisansı gerektirmez. Hepsi, tablonuzu bir sonraki ay açtığınızda sizi bekleyen soruları bugünden hazırlar. Yeni bir rapor kurarken ID sütununu ilk sıraya koyun, ham veriyi yanında tutun ve her sayının yanına kısa bir not yazın: bu sayı neyi ölçüyor, eşiği ne? Bir yıl sonra bu notlar, bir sorunun ne zaman başladığını bulmanızda en değerli kaynak olur.
Sık yazılan soruların kısa cevapları
En yaygın takip sorularının kısa halleri aşağıdaki SSS bölümünde. Bir şeyi hatırlayın: observability satın alınan bir ürün değildir. Sisteminizin ürettiği verinin, planlamadığınız sorulara cevap verebilme gücüdür.