Observability Temelleri: Log, Metric, Trace Hangisi Neye Yarar

"Observability" kelimesi her yerde, ama altını doldurmak kolay değil. Çoğu ekip bir araç kurar (Prometheus, Datadog, ELK), üç dashboard yapar ve "observability'miz var" der. Sonra ilk gerçek incident'ta ortaya çıkıyor ki observability'leri yok — sadece araçları var.

Observability'nin 3 temel ayağı var: log, metric, trace. Her biri farklı soruya cevap verir. Birini diğerinin yerine koymaya çalıştığınızda da ceza bu — yanlış aracı yanlış soruya atıyorsunuz.

Log: "Ne oldu?" sorusunun cevabı

Log, sistemdeki olayların yazılı kayıtları. Bir isteği başından sonuna kadar takip etmek, bir hatanın detaylarını görmek, bir iş sürecinin adımlarını anlamak için.

Log'un güçlü olduğu yerler:

• Bir hatanın tam detaylı stack trace'i
• Bir iş akışının adım adım seyri
• Kullanıcının ne yaptığı (audit trail)
• Spesifik bir sorunu tekrar oluşturmak için ipucu

Log'un zayıf olduğu yerler:

• Aggregation yapmak (milyonlarca log'dan "kaç tane hata" çıkarmak pahalı)
• Görsel özet (100 satırlık log 1 grafikten 100 kat daha zor okunur)
• Hızlı alert (log'da bir pattern yakalamak gerçek zamanlı değildir)

Kural: log'da bir şey ölçmeye çalışıyorsan, muhtemelen ona metric lazımdır.

Metric: "Ne kadar?" sorusunun cevabı

Metric, sayısal ölçümler. Prometheus, Datadog, CloudWatch gibi sistemler bunun için.

Metric'in güçlü olduğu yerler:

• Aggregation (kaç istek? ortalama latency? 99. percentile?)
• Grafik (zaman serisi, trend analizi)
• Alarm (threshold geçilince)
• Ölçeklenebilirlik (milyonlarca veri noktası, saniyeler içinde sorgulanıyor)

Metric'in zayıf olduğu yerler:

• Bir olayın neden olduğunu anlamak
• Spesifik bir kullanıcının problemini anlamak
• Detaylı stack trace

Kural: metric sana bir şeyin olduğunu söyler — niye olduğunu söylemez. Onun için trace veya log gerek.

Trace: "Nerede zaman harcandı?" sorusunun cevabı

Trace, bir isteğin sistemdeki yolculuğunu takip eder. Bir kullanıcının button'a basması → load balancer → API gateway → servis A → servis B → database → cache → response, bu yolculuğun tamamı bir trace.

Trace'in güçlü olduğu yerler:

• Latency'nin nerede olduğunu bulmak ("3 saniye yanıt zamanı — %80'i DB çağrısında")
• Microservice zincirinde bottleneck tespit
• Dağıtık sistemde "hangi servis suçlu?" sorusunu cevaplamak
• Retry ve downstream hata pattern'lerini görmek

Trace'in zayıf olduğu yerler:

• Aggregate analiz (her trace ayrı, bunları aggregate etmek ayrı araç ister)
• Storage maliyeti (trace'ler büyük, genelde sample'lanır)

Üçünün birlikte kullanımı: bir örnek

Bir müşteri şikayet ediyor: "Uygulama yavaş."

Metric'te bak: p99 latency son 30 dakikada 800ms → 2.3s'e çıkmış. Ne kadar kötü, görüyoruz.

Trace'e dön: yavaş bir isteğin trace'ini aç, nerede zaman harcandığını gör. "Game server API → auth service" çağrısı 1.8 saniye sürmüş. Nerede kötü, görüyoruz.

Log'a dön: auth servisindeki o zaman aralığına bak. "Database connection pool exhausted" hataları görüyorsun. Ne olduğunu gördük.

Üçü de gerekli. Birini atlayınca hikayenin yarısı eksik kalır.

Sık yapılan hatalar

Hata 1: Her şeyi log'a yazmak

"Emin olayım diye hepsini log'luyoruz" → storage maliyeti patlar, log içinden anlamlı şey bulmak çok zor, ekip log kontrol etmeyi bırakır.

Çözüm: log levels kullan (DEBUG/INFO/WARN/ERROR), production'da INFO+ sakla, DEBUG sadece incident sırasında aç.

Hata 2: Aynı şeyi hem log'a hem metric'e yazmak

Bir event olduğunda hem logger.info("user logged in") hem metric.increment("login_count") yazmak çift maliyet.

Çözüm: metric'i tek doğru kaynak say, log'u sadece "metric yeterli değilse" ek detay için ekle.

Hata 3: Trace'i opsiyonel bırakmak

"Trace pahalı, performans kaybı olur" diye kapalı tutmak. Incident anında aktivasyon gerekirse çok geç kalınmış olur.

Çözüm: baştan sampling aç (örn. %1 trace, %100 hata durumunda). Bu, performansa anlamlı bir ek yük getirmez.

Alert'lar

Bu üç ayağın hepsinden alert çıkarabilirsin ama metric bu iş için en uygunu:

• Log-based alert — pattern-matching var, yavaş ve güvenilmez
• Trace-based alert — nadiren var, karmaşık
• Metric-based alert — hızlı, net, ölçülebilir

Alert'lerinizi metric'e bağlayın. "Error rate son 5 dakikada %5'i geçti" gibi. "X log'u 10 kere görüldü" tipi alert'lerin false positive oranı çok yüksek.

Pratik öneri

Yeni bir servisi deploy ediyorsanız minimum şu set olmalı:

• Metric: request count, latency (p50/p95/p99), error rate
• Log: her istek için structured log, her hata için stack trace, her iş akışı adımı için INFO log
• Trace: her istek trace'li (sampling %1 baseline, %100 hatalarda)

Bu üçü kurulu olmadan production'a yollamak, körleme deploy. Olayları göreceksin ama anlayamayacaksın.

Sonuç

Observability "bir araç kurmak" değil, üç farklı aracın her birini doğru soruya bağlamak. Log, metric ve trace birbirinin yerini dolduramaz. Hepsi farklı bilgi verir, birlikte tam resmi gösterirler.

İncident günleri iyi observability'nin değerini gösterir. Kötü observability olan bir ekip incident'ı 4 saatte çözer. İyi olan 40 dakikada çözer. Fark tam burada.