Kurumsal Uygulamalarda Observability: Metrik, Log, Trace

Observability, izlemeden (monitoring) fazlası mı?

Evet — izleme, önceden bildiğiniz soruların panolarıdır; observability, önceden bilmediğiniz sorulara üretim ortamında cevap bulabilme yeteneğidir. 'CPU kaç?' izlemedir; 'bu müşterinin dünkü siparişi hangi serviste, neden 4 saniye bekledi?' observability'dir. Bu yetenek üç sütunla kurulur: metrik, log ve dağıtık iz (trace) — ve asıl değer, üçünün korelasyonundadır.

Üç sütun ve Spring ekosistemindeki karşılıkları

Standart tarafında yön nettir: OpenTelemetry, üç sinyalin toplanması ve taşınması için sektörün ortak dili haline gelmiştir; Spring Boot'un güncel sürümleri Micrometer köprüleriyle bu ekosisteme yerleşik bağlanır. Araç seçiminden bağımsız ilke: enstrümantasyon uygulama koduna değil, standart katmana yaslanmalıdır — böylece arka uç (vendor) değişse bile telemetri kalır.

Korelasyon: sütunları birleştiren iplik

Üç sütun ayrı panolarda yaşadığında değil, tek kimlikle birbirine bağlandığında güç üretir: her istek bir trace kimliği taşır; log satırları bu kimliği (MDC üzerinden) otomatik içerir; metrik örnekleri (exemplar) ilgili trace'e işaret eder. Sonuç şu akıştır: panoda p99 sıçramasını görürsünüz → örnek trace'e tıklarsınız → yavaş span'ı bulursunuz → o span'ın loglarına tek kimlikle inersiniz. Bu zincirin her halkası kurulum ister; ama kurulduğunda ortalama teşhis süresi saatlerden dakikalara iner.

Yapılandırılmış loglama: log bir veridir

Metin loglar insan içindir; üretim logları makine içindir. JSON formatlı, alanları standart (timestamp, seviye, servis, trace_id, tenant/müşteri bağlamı) loglar; merkezî arama, alan bazlı filtre ve alarm kuralları için ön koşuldur. İki disiplin eşlik eder: hassas veri maskeleme (kişisel veri ve sırlar loga inmez) ve hacim yönetimi — seviyelerin doğru kullanımı, örneklem (sampling) ve saklama politikası, log faturasının kontrolüdür. 'Her şeyi DEBUG'da topla' yaklaşımı observability değil, maliyet ve gürültüdür.

Metrik tasarımı: RED/USE ve etiket disiplini

Servis metriklerinde RED çerçevesi (Rate, Errors, Duration) asgari settir; kaynaklar için USE (Utilization, Saturation, Errors) eklenir. Micrometer ile özel iş metrikleri (sipariş adedi, ödeme hatası, kuyruğa yazma süresi) aynı boru hattına akar — teknik ve iş panosu aynı veriden beslenir. Kritik disiplin etiketlerdedir: yüksek kardinaliteli etiket (kullanıcı kimliği gibi) metrik sistemini şişirir; etiket seti bilinçli ve sınırlı seçilir, birey bazlı analiz trace/log tarafına bırakılır.

Alarm tasarımı: semptoma alarm, nedene pano

Alarm felsefesinin özeti: kullanıcıyı etkileyen semptomlara (hata oranı, p99, kuyruk gecikmesi) alarm kurulur; nedenler (CPU, GC, havuz doluluğu) panoda teşhis için durur. Her alarmın bir runbook'u ve bir sahibi olmalıdır; art arda tetiklenen ama aksiyon üretmeyen alarm, ekipte alarm körlüğü yaratır ve gerçek olayda maliyet çıkarır. SLO temelli yaklaşım — hedef, hata bütçesi, bütçe tükenme hızına alarm — alarm gürültüsünü mühendislik disipliniyle azaltmanın kanıtlanmış yoludur.

İş etkisi: teşhis süresi bir maliyet kalemidir

Kesinti anında kaybedilen her dakika ciro, itibar ve SLA cezası olarak yazılır; observability yatırımının getirisi tam burada ölçülür: olay başına ortalama teşhis/çözüm süresinin (MTTR) düşmesi. İkinci getiri sözleşmeseldir: kurumsal müşterilere SLO taahhüdü verebilmek, ancak bu altyapıyla mümkündür — 'yüzde 99,9 diyoruz çünkü ölçüyoruz' cümlesi, satış görüşmesinde güçlü bir cümledir. Üçüncüsü kültüreldir: veriye bakan ekip, tartışmayı tahminden ölçüme taşır.

Sık sorulan sorular

Üç sütunun hepsi şart mı; neyle başlamalıyım?

Metrik + yapılandırılmış logla başlayın; korelasyon kimliğini ilk günden ekleyin. Trace, servis sayısı arttığında en yüksek getiriyi verir — mimari dağıtıklaştıkça önceliği yükselir.

Örnekleme (sampling) veri kaybettirmez mi?

Trace'te tam kayıt çoğu ölçekte gereksiz ve pahalıdır; kuyruk temelli/hata öncelikli örnekleme (hatalı ve yavaş izler her zaman tutulur) pratik dengedir.

Hangi arka ucu seçmeliyim?

OpenTelemetry ile enstrümante ederseniz arka uç (açık kaynak yığın veya ticari APM) değiştirilebilir bir karar haline gelir. Kilitlenme, enstrümantasyonda değil veri sahipliğinde önlenir.

Logda kişisel veri yönetimi nasıl kurulur?

Maskeme filtreleri merkezî loglama katmanına konur; alan bazlı erişim ve saklama süreleri KVKK/GDPR envanteriyle hizalanır. Log da bir kişisel veri deposudur ve öyle yönetilmelidir.

Observability kontrol listesi

1. Micrometer metrikleri + RED panoları aktif

2. Loglar JSON; trace_id tüm satırlarda (MDC)

3. OpenTelemetry ile dağıtık iz ve örnekleme politikası kurulu

4. Metrik-trace-log korelasyon zinciri uçtan uca çalışıyor

5. Etiket kardinalitesi denetleniyor; hassas veri maskeleme aktif

6. Alarmlar semptom bazlı; her alarmın runbook'u ve sahibi var

7. SLO'lar tanımlı; hata bütçesi raporlanıyor

SSH Yazılım, Spring tabanlı sistemlerde observability altyapısını — enstrümantasyondan alarm tasarımına — uçtan uca kurar. Teşhis sürenizi birlikte dakikalara indirelim.