Bir uygulama tek süreçte çalışırken hata ayıklamak görece doğrudandır: hata kaydını açar, ilgili stack trace'i bulur ve o anın loglarına bakarsınız. İstek bir API gateway, kimlik servisi, mesaj kuyruğu, arka plan çalışanı ve üçüncü taraf sağlayıcı arasında dolaşmaya başladığında aynı yöntem yetersiz kalır. “Kullanıcı ödeme yapamadı” cümlesi artık tek bir hata değil; zaman içinde ve farklı bileşenlerde gerçekleşen bir olay zinciridir.
Gözlemlenebilirlik bu zinciri sonradan tahmin etmek değil, sistem çalışırken görünür kılmaktır. İyi bir kurulumda ekip şu üç soruya hızlıca cevap verebilir: Ne oldu? Nerede oldu? Neden oldu? Loglar ayrıntılı olayı, metric'ler sistemin genel davranışını, trace'ler ise tek bir isteğin uçtan uca yolculuğunu anlatır. Bu üç sinyal birbirinin alternatifi değil, tamamlayıcısıdır.
Önce sorun senaryolarını tanımlayın
Gözlemlenebilirlik bir araç kurulumu ile başlamamalı. Önce gerçekten cevaplamak istediğiniz operasyon sorularını yazmak daha faydalıdır:
- Bir kullanıcı isteği neden yavaşladı?
- Hangi endpoint hata oranını artırdı?
- Bir kuyruktaki mesajlar neden gecikiyor?
- Aynı hatadan kaç kullanıcı etkilendi?
- Bir dış servis yavaşladığında hangi iş akışları etkileniyor?
Bu sorular, hangi sinyale ihtiyaç duyulduğunu belirler. Örneğin gecikmenin hangi serviste oluştuğunu bulmak için trace gerekir; son bir saatte hata oranının arttığını görmek için metric; tek bir kullanıcının iş akışını anlamak için ise bağlamlı log gerekir. “Her şeyi loglayalım” yaklaşımı yüksek maliyetli, gürültülü ve çoğu zaman cevap vermeyen bir sistem üretir.
Bir isteğe ortak bir kimlik verin
Dağıtık iz sürmenin temel yapı taşı correlation ID veya trace context'tir. İstek sisteme ilk girdiğinde bir trace kimliği oluşturulur ya da üst sistemden gelen geçerli bağlam kabul edilir. Bu kimlik HTTP çağrılarında, kuyruk mesajlarında ve arka plan işlerinde taşınır.
Kritik nokta, kimliğin yalnızca log satırına yazılması değildir. Her yeni span veya alt işlem, üst işlemin bağlamını devralmalıdır. Böylece bir API isteğinden başlayan yol; veritabanı sorgusuna, başka bir HTTP isteğine ve asenkron bir tüketiciye kadar tek bir ağaçta izlenebilir.
Kuyruk tabanlı mimarilerde bağlamı mesaj başlıklarına koymak gerekir. Tüketici mesajı işlediğinde yeni, bağımsız bir işlem başlatmak yerine mesajın iz bağlamını devam ettirir. Aksi hâlde asenkron geçişler tam da en çok ihtiyaç duyulan yerde trace ağacını koparır.
Trace'ler yolculuğu, metric'ler eğilimi gösterir
Trace, bir kullanıcının belirli isteğinde nelerin ne kadar sürdüğünü gösterir. Bir span, örneğin GET /orders, PostgreSQL sorgusu, Redis erişimi veya ödeme sağlayıcısına yapılan çağrı olabilir. Span'a operasyon adı, süre, sonuç durumu ve küçük, sınırlı etiketler eklenir.
Metric ise tek bir isteğin ayrıntısını değil, toplu davranışı gösterir. İstek sayısı, hata sayısı, kuyruk uzunluğu, işleme süresi ve aktif bağlantı sayısı gibi ölçümler zaman serisi olarak izlenir. Özellikle gecikmede ortalama tek başına yanıltıcıdır. Kullanıcıların yavaş deneyimini görmek için p95 veya p99 gibi yüzdelik dilimler daha anlamlı olabilir.
İki sinyal birlikte güçlüdür: dashboard p95 gecikmenin yükseldiğini gösterir; trace bu artışın hangi bağımlılık veya sorgudan kaynaklandığını açıklar. Trace'i sadece tekil hata için, metric'i sadece yöneticiler için düşünmek bu ilişkiyi kaybettirir.
Logları yapılandırılmış ve bağlamlı tutun
Log satırları yalnızca insanın okuyacağı metinler olursa sorgulamak zorlaşır. JSON benzeri yapılandırılmış loglar; zaman, seviye, servis adı, ortam, trace ID, span ID, işlem adı ve hata türü gibi alanların güvenilir biçimde filtrelenmesini sağlar.
Ancak bağlam eklemek, hassas veriyi loglamak anlamına gelmez. Parola, erişim belirteci, tam ödeme verisi veya kişisel belge içeriği asla loga yazılmamalıdır. Kullanıcı kimliği gerekiyorsa, saklama politikasına uygun takma ad veya teknik kimlik kullanmak daha güvenlidir. Loglama bir teşhis aracıdır; ikinci bir veri deposu olmamalıdır.
Hata kaydı için istisna sınıfı, hata kodu, bağımlılık adı ve tekrar deneme bilgisi yararlı olabilir. “İşlem başarısız” gibi genel metinler yerine, ekibin hata türlerini gruplayabileceği tutarlı alanlar seçilmelidir.
Operasyon adlarını ve etiketleri sınırlayın
Kötü adlandırılmış trace'ler de arama yapılması zor loglar kadar değersizdir. GET /users/123 gibi kullanıcı kimliği içeren route'lar yerine GET /users/{id} kullanmak gerekir. Aynı ilke metric etiketleri için daha da önemlidir: kullanıcı kimliği, e-posta, rastgele istek ID'si veya sınırsız URL dizisi gibi yüksek kardinaliteli etiketler metric sistemini pahalı ve yavaş hale getirir.
İyi etiketler sonlu ve anlamlıdır: HTTP metodu, sonuç sınıfı, servis adı, kuyruk adı, veri merkezi veya özellik sürümü. Bir etiketi eklemeden önce şu soru sorulabilir: “Bu alanı kaç farklı değerle gruplamak istiyorum?” Cevap sınırsızsa, o veri çoğunlukla metric etiketi değil log veya trace özniteliğidir.
Alarmı kullanıcı etkisine bağlayın
Her hata alarm üretmemelidir. Kısa süreli tek bir 404 veya tekrar denenip başarıya ulaşan geçici bir hata, gece yarısı çağrı gerektirmeyebilir. Alarm kuralları kullanıcı etkisini, hata bütçesini ve sürekliliği hesaba katmalıdır.
Örneğin “beş dakika boyunca p95 gecikme hedefin üzerinde ve istek hacmi anlamlı” kuralı, tek bir yavaş isteğe göre daha sağlıklı bir sinyaldir. Kuyruklarda yalnızca derinlik değil, en eski mesajın yaşı da izlenmelidir; düşük hacimli ama saatlerdir bekleyen bir mesaj ciddi bir iş sorunu olabilir.
Her alarmın kısa bir çalışma notu olmalıdır: hangi dashboard açılır, hangi trace sorgulanır, ilk güvenli adım nedir ve ne zaman eskalasyon gerekir? Alarm, sorunu haber vermekle kalmamalı; incelemeye başlama maliyetini düşürmelidir.
Küçük bir sözleşmeyle başlayın
Tüm sistemde bir anda kusursuz telemetry üretmek gerekmez. Önce istek girişlerinde trace bağlamı, temel HTTP metric'leri ve yapılandırılmış hata logları ile başlanabilir. Ardından en kritik iki bağımlılık, kuyruk tüketicileri ve en değerli iş akışları eklenir.
Başarı ölçütü panellerin sayısı değil, bir olay sırasında cevaba ulaşma süresidir. Bir istek hangi serviste yavaşladı, hangi bağımlılık hata verdi ve kaç kullanıcı etkilendi sorularını dakikalar içinde yanıtlayabiliyorsanız, gözlemlenebilirlik altyapısı işini yapıyordur.