Gözlemlenebilirliğin üç sütunu: log, metric, trace pratiği

OpenTelemetry, Loki, VictoriaMetrics ve Tempo ile üretimde gerçekten kullanışlı bir gözlemlenebilirlik mimarisi nasıl kurulur.

Tarih 8 Şub 2026

Yazar Murat Haktanır

Okuma süresi 3 dk

“3 sütun” (log, metric, trace) klişesi kötü bir slogan değil; ama kuruluşların büyük çoğunluğu yalnızca metric’i ciddi kuruyor; logları “her şey gelir” felsefesiyle yığıyor; trace’e hiç dokunmuyor. Sonuç: olay anında üçü birden bakılan ama hiçbiri soruyu cevaplayamayan bir araç bahçesi.

Asgari hedef: bir olayı 5 dakikada anlat

İyi bir gözlemlenebilirlik kurulumu, bir olay anında 5 dakika içinde şunu söyleyebilmeli:

Hangi servis etkilendi? (metric)
Ne zaman başladı? Ne zaman bitti? (metric + log)
Etkilenen kullanıcı sayısı? (metric)
Hata mesajı / stack trace? (log)
Yavaş olan endpoint hangi downstream’i bekledi? (trace)

Eğer bu 5 sorunun cevabını 5 dakikada veremiyorsanız, kurulum yeniden tasarımı işe yarar.

OpenTelemetry: tek SDK

3 sütunu da konuşan tek standart OpenTelemetry. Uygulamalara her sütun için ayrı kütüphane (Prometheus client, Sentry SDK, Jaeger client) eklemek 2026’da artık tartışmalı.

Uygulama --[OTLP]--> OpenTelemetry Collector --+--> VictoriaMetrics  (metric)
                                                +--> Loki              (log)
                                                +--> Tempo             (trace)

OTel Collector, bir kez uygulama tarafına eklenir; çıkış arkalarını siz seçersiniz. Yarın Loki yerine ELK’ye geçmek istiyorsanız, sadece collector’ün exporter’ını değiştirirsiniz.

Logger seçimi

Üretim Linux’larında log kaynağı genelde 3 kanaldan gelir:

Uygulama stdout/stderr → konteyner runtime → Loki agent (Promtail / Alloy).
Sistem journald → systemd-journal-upload veya Vector.
Uygulama OTel Collector üzerinden doğrudan log SDK ile.

Mono kurulumlarında Loki + Alloy kombinasyonu ana akım. Loki’nin avantajı: index’i sadece label’lar üzerinde; depolama maliyeti Elasticsearch’ten 8-10× daha düşük.

Yaygın hata: yüksek-kardinaliteli label

Loki label’larını sırasıyla {job="payment-api", env="prod", region="tr-ist-1"} gibi düşük kardinaliteli tutun. {request_id="..."} label’ı = patlama. Request_id, log mesajının içine girer.

Metric: VictoriaMetrics neden Prometheus değil?

Prometheus harika; ama tek node. Yüksek-yük + uzun-vadeli depolama için VictoriaMetrics cluster veya Mimir tercih ediliyor. Mono’nun görece pratiği:

1-30 node altyapı → Prometheus + Thanos sidecar yeterli.
30-200 node → VictoriaMetrics single (storage + select node).
200+ node → VictoriaMetrics cluster (vminsert + vmselect + vmstorage).

VictoriaMetrics’in dahili dedup’u, multi-tenant desteği ve düşük disk-IOPS ihtiyacı üretim için tercih sebebi.

Trace: çoğunluk neden başarmaz?

Trace eklendiğinde 2 hata olur:

Tüm istekler trace edilir → veri patlaması, depolama maliyeti.
Hiçbir istek trace edilmez → “açık ama kullanılmıyor”.

Mono önerisi: head-based + tail-based karma sampling.

# Collector pipeline
processors:
  tail_sampling:
    decision_wait: 10s
    policies:
      - name: errors
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: slow
        type: latency
        latency: { threshold_ms: 1000 }
      - name: probabilistic
        type: probabilistic
        probabilistic: { sampling_percentage: 5 }

Akıl: hata varsa kesin trace tutulur; yavaşsa kesin; geri kalanından %5’i. Hem maliyet kontrol altında hem ihtiyacınız olan trace’leriniz var.

Korelasyon: log ↔ trace ↔ metric

Üç sütunun birleştiği yer: trace_id.

Log mesajları içine trace_id ekleyin (logger middleware).
Grafana Tempo + Loki + VictoriaMetrics tek source’ta birleştir.
Bir alarm metric ile geldiğinde, link üzerinden ilgili trace’e ve log’a tek-tıkla geçiş.

Bu küçük detay (trace_id propagation) kurulumun kullanılır olmasını sağlayan tek şey.

Maliyet kontrolü

Gözlemlenebilirlik kötü kurulduğunda altyapının maliyetini geçer. Pratik kurallar:

Log retention sıcak (Loki) 7-14 gün; soğuk (S3) 90+ gün.
Metric retention raw 14-30 gün; downsampled 1 yıl+.
Trace retention 7 gün yeterli (gerçek olay analizi için).
Cardinality budget her servise label kombinasyon limiti (örn. 10K).

Mono’nun pratiği

Üretimde 80+ servis + 200+ node ortamında:

Loki 40 GB/gün (sıkıştırılmış); $0.05/GB civarı maliyet.
VictoriaMetrics 3M aktif seri.
Tempo 0.8 TB/gün (tail-sampling sonrası).
Toplam gözlemlenebilirlik altyapı maliyeti: kurum yıllık IT bütçesinin %2’si altında.

Sıradaki adımlar

Mevcut gözlemlenebilirlik altyapınızın değerlendirmesi için Yazılım geliştirme yaşam döngüsü tasarımı (SDLC) ve DevOps, konteyner ve mikroservis tasarım ve yönetimi hizmetlerimiz kapsamında 1 haftalık keşif çalışması yapıyoruz.