Metrik, Log, İz ve Hata Takibi: Dördü Neden Ayrı İhtiyaçtır

"İzleme" (monitoring) çoğu ekipte tek bir kelimeyle anılır ama arkasında dört farklı veri türü durur: metrik, log, iz (trace) ve hata takibi. Bunları birbirinin yerine kullanmaya çalışmak, bir arıza anında yanlış yere bakmakla sonuçlanır. Dördü de "sistemde ne oluyor" sorusuna cevap verir, ama farklı ölçekte, farklı maliyetle ve farklı ayrıntı seviyesinde.

Metrikler: eğilimi gösterir, nedeni göstermez

Metrik, zaman içinde toplanan sayısal bir seridir: saniyede kaç istek geldi, kaçı hata döndü, gecikme dağılımı nasıl. RED yöntemi (rate, errors, duration) ve USE yöntemi (utilization, saturation, errors) bu yüzden hâlâ en kullanışlı başlangıç noktasıdır; ikisi de "hangi metriği önce topla" sorusuna kısa bir cevap verir.

Metriğin gücü ucuz olmasından gelir. Bir sayaç veya histogram, milyonlarca isteği tek bir zaman serisine indirger, bu yüzden aylarca saklanabilir ve saniyeler içinde sorgulanabilir. Aynı güç bir sınır da koyar: metrik toplu bir özettir, tek bir isteğin hikâyesini anlatmaz. "Hata oranı yüzde üçe çıktı" bilgisi bir alarmı tetiklemeye yeter ama hangi kullanıcının, hangi parametreyle, hangi servis çağrısında hata aldığını söylemez.

Buradaki en sık tuzak, metrik etiketlerine (label) yüksek kardinaliteli değerler koymaktır: kullanıcı kimliği, istek kimliği, tam URL. Prometheus gibi zaman serisi veritabanları her etiket kombinasyonunu ayrı bir seri olarak saklar; kullanıcı kimliğini etikete koymak, kullanıcı sayısı kadar seri açmak demektir. Sonuç bellek tüketiminin patlaması ve sorgu süresinin dakikalara çıkmasıdır. Kardinalitesi yüksek olan her şey loga ya da ize gitmeli, metrik etiketi olarak kalmamalı.

Loglar: ayrıntı verir, ölçek pahalıdır

Log, belirli bir anda olan tek bir olayın kaydıdır. Metriğin veremediği ayrıntıyı verir: hangi kullanıcı, hangi girdi, hangi hata mesajı. Ama bu ayrıntının bedeli depolama ve arama maliyetidir; her istek için birkaç satır log üretmek, günlük trafiği yüksek bir sistemde kısa sürede terabaytlara çıkar.

Yapılandırılmamış (düz metin) loglar bu maliyeti daha da kötüleştirir, çünkü aramak regex'e kalır ve alanlar arası korelasyon neredeyse imkânsızdır. Yapılandırılmış log (JSON, anahtar-değer) her satıra alanlar ekler; en kritik alan bir istek kimliği veya iz kimliğidir (trace id). Bu kimlik olmadan, bir kullanıcının şikâyet ettiği tek isteğin loglarını binlerce satır arasından bulmak saman yığınında iğne aramaktır.

İzler: isteğin servisler arasındaki yolculuğu

Bir istek tek bir serviste bitmiyorsa (bir ağ geçidi, birkaç mikroservis, bir kuyruk, bir veritabanı) o isteğin toplam gecikmesinin nerede biriktiğini metrik ya da log tek başına söyleyemez. İz, bir isteğin sistem içindeki her adımını (span) zaman damgası ve süreyle birbirine bağlar; W3C Trace Context standardının traceparent başlığı bu bağlamı servisler arasında taşıyan ortak formattır.

İzin asıl faydası dağıtık sistemlerde gecikme kaynağını bulmaktır: "toplam istek 800 milisaniye sürdü" bilgisi tek başına işe yaramaz, ama izde "bunun 650 milisaniyesi üçüncü bir servise yapılan senkron çağrıda geçti" görülünce optimizasyon hedefi netleşir. Zorluğu, her adımın izlenebilir olması için kodun (ya da en azından kütüphanelerin) bağlamı bir sonraki çağrıya taşımasıdır; bu bağlam bir kuyruğa mesaj koyarken ya da arka plan işine geçerken kolayca kopar, çünkü kuyruk mesajı çoğu zaman yalnız iş verisini taşır, iz kimliğini taşımaz. Kopan bağlam, izin ortasında bir boşluk olarak görünür ve gerçek gecikme kaynağı görünmez kalır.

Her isteği baştan sona izlemek çoğu sistemde maliyetlidir, bu yüzden örnekleme (sampling) kaçınılmazdır. Baş örnekleme (head-based) her isteğin başında rastgele karar verir, uygulaması kolaydır ama nadir görülen yavaş bir isteği kaçırma ihtimali yüksektir. Kuyruk sonu örnekleme (tail-based) tüm izi topladıktan sonra karar verir, "hata var" ya da "gecikme eşiği aşıldı" gibi izleri her zaman saklar; kurulumu daha zordur ama tam da aranan anormal örnekleri kaçırmaz.

Hata takibi: log değil, gruplama motoru

Hata takip araçları loglarla karıştırılır ama işlevleri farklıdır. Bir log toplayıcıya her istisnayı ayrı satır olarak göndermek, aynı hatanın bin kez tekrarladığı bir günde bin satır üretir ve hangisinin yeni, hangisinin bilinen bir sorun olduğunu ayırt etmek insana kalır. Hata takip aracının asıl değeri gruplamadır (fingerprinting): aynı yığın izine (stack trace) sahip istisnaları tek bir kayıt altında toplar, kaç kez olduğunu, hangi sürümde başladığını, hangi kullanıcıları etkilediğini gösterir.

Bu gruplama bir bedel de getirir: fingerprint algoritması bazen aslında farklı olan iki hatayı aynı kayıt altında birleştirir (örneğin, farklı satırlarda ama aynı istisna tipinde iki hata), bazen de aynı hatanın küçük bir varyasyonunu (değişen bir değişken adı, farklı bir üçüncü parti kütüphane sürümü) ayrı bir kayıt gibi gösterir. Bu yüzden yeni bir hata takip kurulumunda gruplama kurallarını varsayılan haliyle bırakmak yerine, kendi hata gövdesi biçiminize göre birkaç örnek üzerinde test etmek gerekir.

Pratikte birlikte nasıl çalışırlar

Gerçek bir arıza araştırmasında bu dördü sırayla devreye girer. Önce bir metrik alarmı (hata oranı, p99 gecikme) bir şeyin değiştiğini söyler. Sonra iz, hangi servisin ya da hangi bağımlılığın sorumlu olduğunu daraltır. Sonra o servisin logları, tam olarak hangi girdiyle hangi hatanın oluştuğunu gösterir. Hata takip aracı ise bu tekil olayı aynı kökten gelen diğer olaylarla birleştirip "bu yeni bir hata mı, yoksa bilinen ve zaten iş listesinde olan bir hata mı" sorusuna cevap verir.

Bu zincirin çalışması için tek bir ortak alan gerekir: iz kimliği (trace id). Metrik dışındaki üç sinyal, aynı iz kimliğini taşıdığında birbirine bağlanabilir; log satırına trace id eklemek, hata kaydına trace id eklemek, izin kendi span'larına trace id eklemek, hepsi bu tek alanla mümkün olur. OpenTelemetry'nin popülerleşmesinin asıl sebebi budur: metrik, log ve izi ayrı ayrı toplarken aynı bağlamı taşıyan tek bir kütüphane seti sunması.

Ne zaman dördüne birden yatırım yapmayın

Tek sunucuda çalışan, tek servisli, günde birkaç deploy yapılmayan küçük bir sistemde tam bir gözlemlenebilirlik yığını (metrik toplayıcı, log toplayıcı, iz altyapısı, ayrı hata takip aracı) kurmak, kazanacağından fazla işletim yükü getirir. Böyle bir sistemde yapılandırılmış loglar artı basit bir çalışma süresi kontrolü çoğu zaman yeterlidir; hata takip aracı bile isteğe bağlıdır, çünkü tek servis varken hangi hatanın nereden geldiğini anlamak zor değildir.

Yatırımın karşılığını verdiği eşik, servis sayısı birden fazla olduğunda ve günde birden çok deploy yapıldığında başlar. O noktadan sonra "hangi deploy'dan sonra hata oranı arttı" ya da "gecikme hangi servis sınırında birikiyor" soruları metrik ve log tek başına cevaplanamaz hale gelir, iz zorunlu olur. Sıra bu şekilde işler: önce yapılandırılmış log, sonra metrik ve alarm, sonra hata takibi, en son iz. İzi en başta kurmak, henüz birden fazla servisiniz yokken karmaşıklığı erken satın almaktır.