# Observability Nedir? Tablo Meraklıları İçin Sade Rehber URL: https://formula.dog/tr/journal/observability-nedir Type: blog Locale: tr Published: 2026-10-17 Updated: 2026-10-17 --- > Observability, bir sistemin verileriyle yeni sorular sormanızı sağlar. Loglar, metrikler ve trace'lerin sade anlatımı, Sheets ve Excel'e yapıştırabileceğiniz formüllerle. 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. ![Üç paralel zaman çizelgesi ve pirinç bir kronometre gösteren defter çizimi](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-10/ddbb29-img1.webp) ## 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](https://opentelemetry.io/docs/concepts/observability-primer/) 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. - `COUNTA` ile 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. ![Dizüstü bilgisayarda açık bir tablo ve masada yatan bir köpek pençesi](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-10/824719-img2.webp) Formülü unutan sizseniz, Biscuit onu zaten getirdi. [Formula.dog](https://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](https://opentelemetry.io/docs/concepts/observability-primer/) 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. ![Akşam ışığında masa lambasının yanında halıda yatan bir golden retriever](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-10/a1c8e7-img3.webp) ## 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. ## FAQ ### Observability basitçe ne demek? Bir sistemin ürettiği verilere, yani esas olarak loglara, metriklere ve trace'lere bakarak içinde neyin ters gittiğini, sistemi önce değiştirmeden anlayabilme becerisidir. ### Monitoring ile observability arasındaki fark nedir? Monitoring önceden tanımladığınız koşulları izler ve bunlar bozulunca alarm verir. Observability ise verileri sonradan keşfederek öngörmediğiniz soruların cevabını bulmanızı sağlar. ### Observability'nin üç temel direği nedir? Loglar olayların zaman damgalı kayıtlarıdır, metrikler zaman içinde toplanan sayılardır, trace'ler ise tek bir isteği servisler arasında izler. Birlikte bakıldığında bir şeyin yanlış olduğunu, kabaca nerede olduğunu ve ayrıntısını gösterirler. ### Başlamak için özel araçlara ihtiyacım var mı? Fikirleri öğrenmek için hayır. Yapılandırılmış bir log dışa aktarımı ve bir tablo, hata oranı ve en yavaş servis gibi soruları yanıtlayabilir. Grafana, Datadog ya da New Relic gibi araçlar hacim ve inceleme hızı arttıkça önem kazanır. ### OpenTelemetry nedir? OpenTelemetry, log, metrik ve trace gibi telemetriyi üretmek ve göndermek için açık bir standarttır. Veriyi saklamaz ya da göstermez, bu yüzden onu seçtiğiniz bir arka uçla birlikte kullanırsınız. ### Observability neden pahalı? Maliyet veri hacmiyle ve kullanıcı ya da sipariş ID'leri gibi yüksek kardinaliteli alanlarla birlikte artar. Sunucu başına ve sinyal başına fiyatlandırma üst üste binebilir, bu yüzden birçok ekip saklama süresi ve örnekleme kuralları belirler.