Observability Nedir? Geliştirici Ekipler İçin Pratik Rehber

Saat gece 02:00. Ödeme endpoint'i her yirmi istekten birinde 500 hatası veriyor, ama dashboard'ların hepsi yeşil. "Sistem sağlıklı görünüyor" ile "kullanıcılar sorun yaşıyor" arasındaki bu boşluk, observability'nin kapatmak için var olduğu boşluk. Observability nedir? Sisteminizin yaydığı verilere (loglar, metrikler ve trace'ler) bakarak içeride ne olduğunu anlayabilme yeteneğidir. Önceden planlamadığınız soruların cevabını bu verilerden bulabiliyorsanız, sisteminiz gözlemlenebilir demektir.

Yazının geri kalanı bu tanımın ayrıntısı.

Observability mi monitoring mi: hiç alarm yazmadığınız soru

Monitoring, zaten sormayı bildiğiniz soruları yanıtlar. CPU yüzde 90'ı geçti mi? Hata oranı yüzde 2'nin üstünde mi? Kuyruk büyüyor mu? Metriği siz seçersiniz, eşiği siz koyarsınız, eşik aşılınca nöbetçinin telefonu öter.

Observability ise sormayı bilmediğiniz soruyu yanıtlar. Neden yalnızca tek bir kiracının, tek bir uygulama sürümünde, belirli bir deploy'dan sonra gelen istekleri dört saniye daha yavaş? Bunun için kimsenin alarmı yoktur, çünkü kimse öngörmemiştir.

Yani ikisi birbirinin rakibi değil. Monitoring uyarı katmanıdır. Observability ise alarm çaldıktan sonra, ya da hiç alarm çalmadan bir müşteri şikayet yazdığında incelemenizi sağlayan şeydir. Yalnızca hazır dashboard duvarınız varsa elinizde monitoring vardır. Üretim verisini istediğiniz her boyuta göre kesebiliyor ve kod yayınlamadan bir isteği servisler arasında takip edebiliyorsanız observability'niz var demektir.

Üç sinyal: metrikler, loglar ve trace'ler

Çoğu tanım "üç sütun" ile başlar. Etiket biraz kasvetli, ama üç veri türü gerçek ve her biri bir işi iyi yapıyor.

• Metrikler zamana göre sayılardır: istek oranı, p95 gecikme, kullanılan bellek. Saklaması ucuz, sorgusu hızlıdır, "bir şey mi ters gidiyor?" sorusu için idealdir. "Hangi istek, neden?" sorusunda yetersiz kalır.

• Loglar ayrık olayların zaman damgalı kayıtlarıdır: bir ödeme başarısız oldu, bir retry tetiklendi, bir feature flag açıldı. Ayrıntıyı taşırlar, ama yoğun bir serviste yapılandırılmamış loglar samanlık olur.

• Trace'ler tek bir isteğin servisler arasındaki izini sürer. Her adım bir span'dir: başlangıcı, süresi ve birkaç özniteliği vardır. Dağıtık bir sistem için bulabileceğiniz en yakın şey bir stack trace'tir.

Grafana'nın 2025 anketi, pratisyenlerin gerçekte nerede olduğunu gösteriyor. Grafana'nın observability anketi, 1.255 katılımcının yüzde 95'inin metrik, yüzde 87'sinin log kullandığını, ama yalnızca yüzde 57'sinin trace kullandığını buldu. Dağıtık bir hatada en çok yardımcı olacak sinyal trace, ama en az kurulan da o.

"Metrikler ne olduğunu, loglar neden olduğunu, trace'ler nerede olduğunu söyler" kısa yolunu atlayın. Kulağa düzgün gelir ama pratikte tutmaz: iyi yapılandırılmış bir log, kötü kurulmuş bir trace'ten çok daha fazla "nerede" bilgisi verebilir.

Bir sistemi pratikte gözlemlenebilir yapan şey

Veri üretmek gereklidir, ama yeterli değildir. Verinin üç özelliği olduğunda sistem gözlemlenebilir olur.

Yüksek kardinalite. Kullanıcı kimliği, kiracı, build SHA, bölge, feature flag gibi boyutlara göre filtreleyebilirsiniz. Aracınız sizi servis adı ve durum koduna göre önceden toplamaya zorluyorsa, kötü durumdaki tek kiracıyı bulamazsınız.

Sinyalleri birbirine bağlayan bağlam. Her log satırında bir trace ID olduğunda, yavaş bir span'den o span'in ürettiği tam loglara geçebilirsiniz. Bu bağ olmadan iki ayrı hikayeyi okur ve nasıl bağlandıklarını tahmin edersiniz.

Kullanışlı olacak kadar ayrıntı, ama karşılanamayacak kadar değil. Çoğu ekibin zorlandığı yer burası. Aynı Grafana anketinde katılımcılar toplamda 100'den fazla farklı araç, servis ve proje saydı; ortalama bir ekip sekiz tane kullanıyordu. Araç seçerken maliyet en önemli kriterlerden biriydi. Her şeyi toplamak kolay. Bunun faturasını ödemek ise insanların sonradan fark ettiği kısım.

OpenTelemetry ile başlangıç noktası şöyle görünür. OpenTelemetry, satıcıdan bağımsız bir enstrümantasyon standardıdır. Aşağıda, bir span oluşturan ve gece 02:00'de işinize yarayacak öznitelikleri ekleyen minimal bir Python örneği var:

from opentelemetry import trace

tracer = trace.get_tracer("checkout")

def charge(order):
    with tracer.start_as_current_span("charge_card") as span:
        span.set_attribute("order.id", order.id)
        span.set_attribute("tenant.id", order.tenant_id)
        span.set_attribute("app.version", APP_VERSION)
        result = payment_client.charge(order)
        span.set_attribute("payment.provider", result.provider)
        return result

Üç öznitelik, "checkout yavaş" ile "4412 numaralı kiracı için, sürüm 3.8.1'de checkout yavaş" arasındaki farkı yaratır. OpenTelemetry observability giriş dokümanı bunun arkasındaki kavramları daha derin anlatıyor. Altyapıyı satıcınız kurmuş olsa bile bir kez okumaya değer.

Bu öznitelikler işe yaradığında, gecikme sorusunu sırayla sorabilirsiniz. Önce gecikmeyi tüm trafikte kesin, sonra aynı kesiti kiracıya göre, ardından sürüme göre ayırın. Üçüncü adımda çoğu zaman tablo bir noktada netleşir: sorun herkeste değil, belirli bir kiracıda ve belirli bir sürümde. Bu noktaya geldiğinizde, o span'in loglarına inmek ve hangi dış çağrının yavaşladığını görmek birkaç dakikalık iş olur. Öznitelikler yoksa aynı soruyu yanıtlamak için kod dağıtmanız, yani tam da observability'nin önlemeye çalıştığı şeyi yapmanız gerekir.

Gözlemleme araçları nerede farklı, nerede farklı değil

Pazarlama dilinin altında çoğu platform aynı üç sinyali alır. Farklar fiyatlandırma modelinde, sorgu gücünde ve enstrümantasyonu sizin yerinize ne kadar yaptıklarında ortaya çıkar. Bir araç seçmeden önce kendinize üç soru sorun. Birincisi, faturanız trafiğinizle birlikte nasıl büyüyecek ve bunu bir ay önceden tahmin edebilecek misiniz? İkincisi, bir kiracıya göre filtreleme yapabiliyor musunuz, yoksa bunun için yeni bir dashboard mı kurmanız gerekiyor? Üçüncüsü, ekibinizin bu aracı günlük işte açıp soru sorması ne kadar kolay? Bu üç soruya verilecek cevaplar, özellik tablolarından çoğu zaman daha fazla şey söyler.

• Her şey bir arada platformlar metrikleri, logları, trace'leri, alarmları ve daha fazlasını tek çatı altında sunar. Kullanımı rahat, ama trafikle birlikte büyüyen kullanım faturası bunun bedelidir.

• Açık kaynak yığınları, örneğin Prometheus, Loki, Tempo ve Grafana, kontrol sağlar ve sunucu başına lisans ücreti olmaz; karşılığında onları kendiniz çalıştırıp ayarlamanız gerekir.

• OpenTelemetry tabanlı arka uçlar standart formatı doğrudan kabul eder; bu sayede sağlayıcı değiştirmek her servisi yeniden enstrümante etmek anlamına gelmez.

Datadog, her şeyi bir arada sunan kategorinin referans noktası: geniş kapsam, cilalı bir arayüz ve her ay gözden geçirilmeyi hak eden bir fatura. Tek satıcıda toplanmak istiyorsanız ve bütçeniz varsa değer. Maliyet öngörülebilirliği en büyük kısıtınızsa atlayın.

Grafana pratik açık kaynak seçimi. Zaten sahip olduğunuz veri üzerine dashboard kurarak başlayabilir, loglar ve trace'leri ihtiyaç doğdukça ekleyebilirsiniz. Biraz mühendislik zamanı yatırmanız gerektiğini unutmayın.

SigNoz baştan OpenTelemetry üzerine kurulmuş ve metrikleri, logları ve trace'leri açık kaynaklı tek bir arayüzde toplar. Tek ekrandan izleme deneyimini, her şeyi kapsayan platformların fiyatı olmadan isteyen bir ekip için makul bir seçim.

New Relic iki dünya arasında duruyor: barındırılan bir platform ve gerçek bir değerlendirme yapmaya yetecek kadar cömert bir ücretsiz katman. Demoya değil, ekibinizin gerçek bir üretim sorusunu bu araçla yanıtlayıp yanıtlayamayacağına bakarak değerlendirin.

Bunlardan hiçbiri tek başına sizi gözlemlenebilir yapmaz. Araç bir sorgulama arayüzüdür. Asıl ürün enstrümantasyondur.

Çoğu rehberin atladığı kısım: observability kod sınırında durur

Bu araçları ciddi şekilde kullanmaya başladığınızda ilk fark edeceğiniz boşluk şu. Bir trace size charge_card adımının 3,9 saniye sürdüğünü ve yavaş kısmın payment_client çağrısı olduğunu söyler. Ama payment_client'ın tam olarak ne yaptığını, kimin yazdığını ya da neden backoff olmadan üç kez yeniden denediğini söylemez.

Bunun için gözlemleme aracını bırakıp kodu okumanız gerekir. Küçük bir serviste bu on dakika sürer. Dört ekibin sahip olduğu 100 bin satırlık bir repoda ise okuma çoğu zaman olayın en uzun kısmıdır. Hangi span'in yavaş olduğunu tam olarak bilirsiniz, ama o span'in arkasındaki kodun nasıl bağlandığını çözmek için bir saat harcarsınız.

Çalışma zamanı verisi ile kaynak kod arasındaki bu devir problemi, observability ile kod anlayışını tek bir iş akışının iki yarısı olarak görmemizin nedeni:

1. Observability, çalışma zamanında nerede olduğunu söyler: hangi servis, hangi span, hangi kiracı.

2. Kod anlayışı, kaynakta neden olduğunu söyler: hangi fonksiyon, hangi retry politikası, hangi konfigürasyon.

Döngüyü kapatan ekipler (span adı bir dosyaya, dosya bir sahibe ve açıklamaya bağlanır) "alarm çaldı" ile "düzeltme anlaşıldı" arasındaki süreyi kısaltır. Bu büyük ölçüde bir disiplin meselesi. Span'lere fonksiyon adlarını verin, repo yolunu bir span özniteliğine koyun ve servis başına kısa bir mimari not tutun. Bir yapay zeka asistanı, "ödeme çağrıları için retry politikası nerede ayarlanmış?" gibi sorulara repo üzerinden cevap verebiliyorsa, dayanacak somut bir zemin bulmuş olur.

Observability'nin işe yaramadığını düşündüren üç hata

Dashboard'ları hedef sanmak. Dashboard, eski bir soruya kaydedilmiş bir cevaptır. Kırk tane kurup hiç ad hoc sorgu yazmayan ekipler, daha güzel bir ambalajda monitoring kullanır. Her olayda kendinize sorun: bunu bir dashboard'dan mı yanıtladık, yoksa ham veriyi keşfederek mi?

Örneklemeyi çok erken yapmak ya da hiç yapmamak. Yoğun bir serviste trace'lerin yüzde 100'ünü tutmak hızla pahalıya patlar. Rastgele yüzde 1'ini tutmak ise umursadığınız nadir hatalı isteği atar. Yavaş ve hatalı trace'leri tutup sağlıklıların çoğunu atan kuyruk tabanlı örnekleme (tail-based sampling) genelde kabul gören uzlaşmadır. Kararı ilk faturadan önce verin, sonra değil.

Öznitelik adlarının kaymasına izin vermek. Bir servis user_id, bir diğeri userId, üçüncüsü uid yazar. Artık üçünü de kapsaması gereken sorgu, tablonun üçte birini döndürür. Kiracı, kullanıcı, sürüm ve flag öznitelikleri için küçük bir isimlendirme kuralı üzerinde anlaşın ve insanların bulacağı bir yere, repoya yazın.

Bunların hiçbiri araç sorunu değil. Alışkanlık sorunu ve alışkanlıklar, satıcı değiştirmekten daha ucuza düzeltilir.

Her şeyi enstrümante etmeden nasıl başlanır

Bugün hiçbir şeyiniz yoksa, ilk haftada her şeyi enstrümante etme dürtüsüne direnin. 5 ila 50 mühendisli ekipler için işe yarayan bir sıra şöyle:

1. Tek bir kritik kullanıcı akışı seçin. Ödeme, kayıt olma veya ana API çağrısı. Tüm sistemi değil.

2. İstek kimliğiyle yapılandırılmış loglar ekleyin. JSON, satır başına bir olay ve her satırda trace ya da istek ID'si.

3. Bu akışı OpenTelemetry trace'leriyle enstrümante edin. Yukarıdaki örnekteki kiracı, sürüm ve flag öznitelikleri dahil olsun.

4. İki ya da üç servis seviyesi hedefi (SLO) tanımlayın. Örneğin ödeme isteklerinin yüzde 99,5'inin 800 ms altında başarılı olması. Alarmlar CPU'ya değil, bu hedeflere bağlansın.

5. Gerçek bir olayı veriyle birlikte inceleyin. Yeni kod yazmadan nedeni bulabilir miydiniz? Bulamadıysanız, fark ettiğiniz boşluk bir sonraki enstrümantasyon işinizdir.

Gözlemlenebilir olup olmadığınızı gösteren tek adım 5. numaradır. Diğer her şey tesisat.

Biz gerçekte ne yapardık

Ekibiniz 20 mühendisin altındaysa, OpenTelemetry enstrümantasyonuyla başlayın ve fiyatını önceden tahmin edebildiğiniz bir arka uç seçin. Enstrümantasyon taşınabilir, dolayısıyla arka uç seçimi geri alınabilir. Rakibiniz yaptı diye en büyük platformu almayın.

Pratikte ilk iki haftayı şöyle planlayabilirsiniz. İlk hafta, seçtiğiniz kritik akıştaki logları yapılandırın ve istek kimliğini her satıra ekleyin. Bu tek başına bile, bir müşteri şikayetini hangi isteğe bağlayacağınızı bulmanızı kolaylaştırır. İkinci hafta, aynı akışa trace'leri ve üç öznitelik ekleyin, sonra ilk gösterge panelinizi kurun. Panel, hangi sorunun sürekli sorulduğunu gösterecek kadar sade olsun. Her iki haftanın sonunda ekipten biri, geçen ayın bir olayını yeni kod yazmadan yeniden anlatabiliyorsa, işe doğru yerden başlamışsınız demektir. Anlatamıyorsa, eksik olan genellikle yeni bir araç değil, bir öznitelik ya da bir bağlantıdır.

Zaten her şeyi kapsayan bir araç için ödüyorsanız, sökmeyin. Neyi topladığınızı denetleyin, kimsenin sorgulamadığı logları kaldırın ve tasarruf ettiğiniz parayı önemli akışları enstrümante etmeye harcayın.

Hangi yolu seçerseniz seçin, bir span'in koda nasıl geri bağlandığını yazılı olarak tutun. Dashboard size yangını gösterir. Yangının neden başladığını öğrenmek için yine birinin kaynak kodu okuması gerekir.