Bunlar gözlenebilirliğin üç ayağıdır. Farklı sorulara cevap verirler: metrikler size olduğunu söyler, loglar söyler ve izler zamanın veya hatasının gittiğini söyler.
Bunlar gözlenebilirliğin üç ayağıdır. Farklı sorulara cevap verirler: metrikler size olduğunu söyler, loglar söyler ve izler zamanın veya hatasının gittiğini söyler.
METRICS aggregate numbers over time (counters, gauges, histograms)
→ cheap, low cardinality, great for trends & ALERTING
→ e.g. error rate = 2%, p99 latency = 800ms
LOGS discrete, timestamped events with detail (often structured JSON)
→ rich context for DEBUGGING a specific request
→ e.g. {"level":"error","user":123,"msg":"payment declined"}
TRACES the path of one request across services, with timing per span
→ shows latency BREAKDOWN and where a call fails
→ e.g. checkout 800ms = api 50ms + db 700ms + email 50ms
1. METRIC alerts: "checkout p99 latency jumped to 2s" → you know THERE's a problem
2. TRACE a slow request: 1.8s of 2s is spent in the inventory service
→ you know WHERE it is
3. LOGS of the inventory service at that time: "slow query: missing index"
→ you know WHAT happened
Metrikler sizi bir semptom ve zaman penceresine daraltır; izler bunu bir hizmet veya çağrıya yerelleştirir; loglar kesin nedeni sağlar. Metrikler olmadan doğrudan loglara gitmek körü körüne arama anlamına gelir.
Metrikler toplandığından, ölçekte bile ucuz kalırlar — her zaman açık kontrol panelleri ve uyarılar için idealdir. Loglar ve izler olay başınadır ve pahalıdır, bu nedenle genellikle örneklenirler ve araştırma sırasında talep üzerine sorgulanırlar.
Yanlış ayağı kullanmak zaman kaybı: ham loglarda etkili bir şekilde uyar veremezsiniz (çok gürültülü, çok pahalı) ve bir toplam metrikten belirli bir başarısız isteği ayıklanamaz. Metriklerin tespit ettiğini, izlerin yerelleştirdiğini ve logların açıkladığını bilmek, "bir şey yanlış" durumundan temel nedene kadar hızlı, yinelenebilir bir yol sağlar.
Junior'dan Senior'a detaylı cevaplarla bir BT mülakat soruları kütüphanesi.
Bağış Yap