İçeriğe geç
Yeni yazı çıkınca e-posta · 4.812 abone 190 rehber · 78 ipucu · 58 komut RSS GitHub LinkedIn İletişim
Ara Ctrl K Bültene katıl
Tüm arşiv · 190 rehber →
Tüm araçlar · 75 üreteç →
Gözlemlenebilirlik

Metrik, günlük ve iz: üç sinyal neyi anlatır

Üç sinyalin hangi soruyu yanıtladığı, kardinalite tuzağı, örnekleme ve hangisinin ne zaman kullanılacağı.

Mustafa Çelik 25 Ağustos 2026 · 5 dk okuma

Gözlemlenebilirlik üç tür veriye dayanır ve üçü farklı soruları yanıtlar. Hepsini toplamak pahalıdır, hiçbirini toplamamak körlüktür. Ayrımı bilmek, neyi ne kadar saklayacağınızı belirler.

Metrik: “ne kadar” sorusu

Metrik, zamana bağlı sayısal bir ölçümdür: saniyedeki istek sayısı, işlemci kullanımı, kuyruk uzunluğu, hata oranı.

Ucuzdur çünkü toplanır — bir dakikadaki bin isteği tek bir sayı olarak saklarsınız. Uzun süre tutmak da ucuzdur; yıllık eğilim grafikleri bu yüzden metriklerden çıkar.

Yanıtladığı soru şudur: bir şey normal mi, değil mi? Alarmlar neredeyse her zaman metriklerden kurulur.

Yanıtlayamadığı soru ise “neden”: metrik bir sayının yükseldiğini söyler, hangi isteğin neden başarısız olduğunu söylemez.

Günlük: “ne oldu” sorusu

Günlük, belirli bir anda gerçekleşen bir olayın kaydıdır. Metnin kendisidir; bağlam taşır.

Bir isteğin neden 500 döndüğünü, hangi dosyanın bulunamadığını, hangi kullanıcının hangi işlemi denediğini günlükten öğrenirsiniz.

Bedeli hacimdir. Her olay ayrı bir kayıt olduğu için günlükler hızla büyür ve saklaması pahalıdır. Bu yüzden saklama süresi ve neyin toplanacağı bilinçli bir karardır; ölçütler günlük toplama: neyi saklamalı rehberinde, hacim hesabı günlük saklama aracında.

Yapılandırılmış günlük — düz metin yerine alanlara ayrılmış kayıt — burada büyük fark yaratır: aramak yerine süzebilirsiniz. Linux tarafındaki karşılığı journalctl ile arıza bulmak rehberinde.

İz: “nerede” sorusu

İz (trace), tek bir isteğin sistem içindeki yolculuğunu gösterir. İstek hangi servislere uğradı, her birinde ne kadar zaman geçirdi?

Dağıtık mimarilerde vazgeçilmezdir. Bir sayfanın yavaş açılmasının nedeni beş servisten hangisiyse, izler onu doğrudan gösterir — metrikler yalnızca “yavaş” der, günlükler ise beş ayrı yerde dağınık durur.

Çalışma mantığı, isteğin başında üretilen bir kimliğin tüm çağrılar boyunca taşınmasıdır. Bu kimlik günlüklere de yazılırsa, bir izden ilgili günlüklere doğrudan geçebilirsiniz — üç sinyali birbirine bağlayan şey budur.

Kardinalite tuzağı

Metrik toplarken en pahalı hata budur ve faturayı sessizce katlar.

Bir metriğe eklenen her etiket, olası değer sayısı kadar ayrı zaman serisi üretir. Ülke etiketi eklemek makuldür — sınırlı sayıda değer vardır.

Ama kullanıcı kimliği, istek kimliği ya da tam URL etiketi eklemek felakettir: her farklı değer yeni bir seri açar ve sayı milyonlara çıkar. Depolama patlar, sorgular yavaşlar, maliyet kontrolden çıkar.

Kural nettir: yüksek kardinaliteli veri metriğe değil, günlüğe ya da ize aittir. Metrik etiketleri sınırlı ve öngörülebilir kümelerden seçilmelidir.

Bulut tarafında bu maliyetin nasıl büyüdüğü Cloud Logging maliyeti rehberinde ele alınıyor.

Örnekleme

İzler her istek için toplandığında hacim çok büyür. Bu yüzden genelde örnekleme yapılır: isteklerin küçük bir yüzdesi izlenir.

Sabit oranlı örnekleme basittir ama sorunludur — nadir görülen hatalar örneklemeye düşmeyebilir.

Daha iyi yaklaşım, kararı işlem bittikten sonra vermektir: hata veren ya da yavaş olan istekleri her zaman sakla, normal olanların küçük bir kısmını sakla. Böylece ilgilendiğiniz vakaların hepsi elinizde kalır.

Hangisiyle başlanmalı

Sırayla kurmak, hepsini birden kurmaya çalışmaktan gerçekçidir.

Önce metrikler. Ucuzdur, alarm kurmanızı sağlar ve “bir şey ters” sorusunu yanıtlar.

Sonra günlükler. Merkezî toplama ve arama, “ne oldu” sorusunu yanıtlar.

En son izler. Dağıtık bir mimariniz yoksa değeri sınırlıdır; tek parça bir uygulamada metrik ve günlük çoğu zaman yeter.

Üçü birbirine bağlanmalı

Asıl değer, sinyaller arasında geçiş yapabildiğinizde ortaya çıkar.

Bir alarm çalar (metrik) → o zaman aralığındaki hatalı isteklere bakarsınız (izler) → içlerinden birinin ayrıntısına inersiniz (günlükler).

Bu zincir kurulmamışsa üç ayrı araç, üç ayrı sekmede açık durur ve olay incelemesi el yordamıyla yürür. Ortak bir kimlik ve ortak etiketler — servis adı, ortam, sürüm — bu bağı kuran şeydir.

Toplamak yetmez

Sık yapılan hata, veri toplamayı gözlemlenebilirlik sanmaktır. Kimsenin bakmadığı bir gösterge paneli, kimsenin okumadığı bir günlük deposu değer üretmez.

Ölçüt şudur: bir olay sırasında nereye bakacağınızı biliyor musunuz? Yanıt “birkaç yere bakarız” ise, toplanan verinin miktarı değil düzeni sorunludur.

Alarmların neye bakması gerektiği alarm belirtiye mi nedene mi rehberinde, nöbet tarafı nöbet ve devir teslim rehberinde.

Kısaca

Metrik “ne kadar”, günlük “ne oldu”, iz “nerede” sorusunu yanıtlar. Metrikler ucuz ve alarm içindir; günlükler bağlam taşır ve pahalıdır; izler dağıtık sistemlerde darboğazı gösterir.

İki kural maliyeti ve faydayı birlikte belirler: yüksek kardinaliteli veriyi metriğe koymayın, ve üç sinyali ortak bir kimlikle birbirine bağlayın.

Mustafa Çelik

Altyapı ve Operasyon Müdürü, İstanbul. 25 yıldır BT altyapısı, sistem yönetimi ve ağ altyapısıyla uğraşıyor; öğrendiklerini bu blogda üretim ortamında denenmiş rehberlere çeviriyor.

Hakkımda

Bu rehber işinize yaradıysa, sonrakini kaçırmayın.

Yeni yazı yayınlandığında tek e-posta. Takvim yok, dilediğiniz an çıkabilirsiniz.

Bülten sağlayıcısı henüz bağlanmadı. Bağlanana kadar e-posta ile yazabilirsiniz ya da RSS akışını takip edebilirsiniz.