Log ve metrik toplama

Üretim ortamında bir mikro servis yavaşladığında veya hata oranı yükseldiğinde, ekip genellikle önce loglara, ardından metriklere bakar. Dağıtık mimarilerde bu iki sinyal tek başına yeterli değildir; gözlemlenebilirlik üç temel sütuna dayanır: loglar, metrikler ve izler (traces). Log ve metrik toplama altyapısı doğru kurulmadığında, olay müdahalesi dakikalar yerine saatler sürer ve kök neden analizi tahmine dayalı hale gelir.

Gözlemlenebilirliğin üç sütunu

Loglar, belirli bir olayın bağlamını taşır: hangi kullanıcı, hangi istek kimliği, hangi hata mesajı. Metrikler ise zaman içindeki eğilimleri sayısal olarak gösterir: saniyedeki istek sayısı, p99 gecikme, bellek kullanım yüzdesi. İzler ise isteğin servisler arası yolculuğunu görselleştirir. Üç sinyali birbirine bağlamak için korelasyon kimliği (correlation ID) ve trace ID kullanımı zorunludur. Bir HTTP isteği gateway'den geçerken üretilen trace ID, tüm alt servislerde aynı değerle loglanmalıdır.

Log tasarım ilkeleri

Yapılandırılmamış metin logları arama ve filtreleme açısından verimsizdir. Üretim sistemlerinde JSON yapılandırılmış log formatı tercih edilmelidir. Her log satırında asgari olarak şu alanlar bulunmalıdır:

• timestamp: ISO 8601 formatında UTC zaman damgası
• level: DEBUG, INFO, WARN, ERROR seviyeleri
• service: servis adı ve sürüm bilgisi
• trace_id ve span_id: dağıtık izleme için
• message: insan okunabilir açıklama

ASP.NET Core uygulamalarında Serilog ile yapılandırılmış log örneği:

{
  "Serilog": {
    "WriteTo": [
      { "Name": "Console", "Args": { "formatter": "Serilog.Formatting.Compact.CompactJsonFormatter, Serilog.Formatting.Compact" } }
    ],
    "Enrich": [ "FromLogContext", "WithMachineName", "WithThreadId" ]
  }
}

Merkezi log toplama mimarisi

Her pod veya container kendi diskine log yazdığında, pod yeniden başlatıldığında loglar kaybolur. Bu nedenle loglar stdout/stderr üzerinden akıtılmalı ve merkezi bir toplayıcıya yönlendirilmelidir. Yaygın yığınlar şunlardır:

1. Elasticsearch + Logstash + Kibana (ELK): güçlü tam metin arama, yüksek disk tüketimi
2. Loki + Grafana: etiket tabanlı indeksleme, düşük maliyet, Prometheus ile entegrasyon
3. CloudWatch Logs / Azure Monitor: yönetilen servis, operasyonel yük az

Loki mimarisinde loglar object storage'a yazılır; sorgular etiket filtreleriyle daraltılır. Bu yaklaşım yüksek hacimli log ortamlarında maliyet avantajı sağlar. Ancak tam metin arama gereksinimi varsa Elasticsearch daha uygun olabilir.

Log hacmi ve örnekleme

Her isteği DEBUG seviyesinde loglamak, saniyede binlerce istek alan bir API'de günde terabayt log üretebilir. Log seviyesi ortama göre ayarlanmalıdır: geliştirmede DEBUG, üretimde INFO veya WARN. Yüksek trafikli uç noktalarda head-based sampling veya hata durumlarında tam log, başarılı isteklerde özet log stratejisi uygulanabilir.

Metrik toplama: Prometheus modeli

Prometheus, çekme (pull) modeliyle hedeflerden metrik toplar. Her metrik bir isim, etiket kümesi ve sayısal değerden oluşur. Metrik türleri:

• Counter: yalnızca artan sayaç (toplam istek, hata sayısı)
• Gauge: artıp azalan değer (aktif bağlantı, kuyruk uzunluğu)
• Histogram: dağılım ölçümü (istek süresi bucket'ları)
• Summary: quantile hesaplaması (p50, p99 gecikme)

.NET uygulamalarında prometheus-net kütüphanesi HTTP middleware ile otomatik metrik üretir. Özel iş metrikleri için counter ve histogram tanımlanmalıdır.

RED ve USE yöntemleri

Mikro servisler için RED yöntemi önerilir:

• Rate: saniyedeki istek hızı
• Errors: hatalı istek oranı
• Duration: istek süresi dağılımı

Altyapı kaynakları için USE yöntemi kullanılır: Utilization (kullanım), Saturation (doygunluk), Errors (hata). CPU %85 üzerinde ve disk I/O kuyruğu uzuyorsa, uygulama metrikleri normal görünse bile performans düşüşü kaçınılmazdır.

Kardinalite tuzağı

Metrik etiketlerine kullanıcı kimliği veya sipariş numarası gibi yüksek kardinaliteli değerler eklemek, Prometheus bellek tüketimini patlatır. Etiketler düşük kardinaliteli olmalıdır: servis adı, ortam, HTTP yöntemi, status code sınıfı (2xx, 4xx, 5xx). Kullanıcı bazlı analiz log ve trace verisiyle yapılmalıdır.

OpenTelemetry ile birleşik toplama

OpenTelemetry (OTel), log, metrik ve trace için vendor-neutral bir SDK sunar. Tek bir enstrümantasyon katmanıyla veriler OTLP protokolü üzerinden collector'a gönderilir. Collector, veriyi Prometheus, Jaeger veya Loki'ye yönlendirebilir. Bu yaklaşım vendor lock-in riskini azaltır ve sinyaller arası korelasyonu kolaylaştırır.

# docker-compose excerpt — OTel Collector
services:
  otel-collector:
    image: otel/opentelemetry-collector-contrib
    volumes:
      - ./otel-config.yaml:/etc/otelcol/config.yaml
    ports:
      - "4317:4317"   # OTLP gRPC
      - "8889:8889"   # Prometheus exporter

Alarm ve SLO tasarımı

Metrik toplamak tek başına yeterli değildir; anlamlı alarmlar tanımlanmalıdır. Her alarm bir runbook ile eşleştirilmelidir. SLO (Service Level Objective) tanımı alarm eşiklerini belirler. Örneğin aylık %99.9 erişilebilirlik hedefi, yaklaşık 43 dakikalık kesinti bütçesi demektir. Error budget tükendiğinde yeni özellik yerine güvenilirlik çalışmalarına öncelik verilir.

Alarm yorgunluğunu önlemek için:

• Belirti (symptom) bazlı alarmlar tercih edin, neden bazlı değil
• Aynı olayı tetikleyen çoklu alarm birleştirin
• On-call rotasyonunda alarm gürültüsü düzenli gözden geçirilsin

Depolama, saklama ve maliyet

Log saklama süresi yasal gereksinimler ve operasyonel ihtiyaçlarla belirlenir. Genellikle sıcak depolama 7-30 gün, soğuk arşiv 90-365 gün yeterlidir. Metrikler için Prometheus'ta varsayılan 15 gün saklama uygundur; uzun dönem trendler için Thanos veya Cortex ile uzaktan okuma katmanı eklenir.

Üretim kontrol listesi

Log ve metrik altyapısını devreye almadan önce şu maddeleri doğrulayın:

1. Tüm servisler yapılandırılmış log üretiyor mu?
2. Trace ID log satırlarında mevcut mu?
3. RED metrikleri dashboard'da görünüyor mu?
4. Kritik SLO'lar için alarm tanımlı mı?
5. Log/metrik saklama maliyeti bütçe içinde mi?
6. Disaster recovery senaryosunda observability verisi erişilebilir mi?

Dağıtık izleme ve servis haritası

Metrikler "ne kadar yavaş" sorusunu yanıtlar; izler ise "nerede yavaş" sorusunu. Jaeger, Zipkin veya Tempo gibi trace backend'leri, isteğin gateway'den veritabanına kadar geçtiği her span'i görselleştirir. Servis haritası (service map) otomatik olarak bağımlılık topolojisini çıkarır; beklenmedik çağrı zincirleri ve döngüsel bağımlılıklar erken tespit edilir.

Trace örnekleme oranı üretimde genellikle %1-10 arasında tutulur. Hata durumlarında tam trace, başarılı isteklerde örneklenmiş trace saklanır. Bu denge depolama maliyetini kontrol altında tutarken olay analizine yeterli veri bırakır.

Log enrichment ve pipeline

Ham log satırları toplandıktan sonra zenginleştirme (enrichment) pipeline'ından geçmelidir. Kubernetes metadata (pod adı, namespace, node), deployment sürümü ve ortam etiketi log kaydına eklenir. Fluent Bit veya Vector gibi hafif toplayıcılar, node üzerinde çalışarak merkezi depoya iletmeden önce bu dönüşümü yapar.

Log pipeline'ında PII (kişisel veri) maskeleme adımı zorunludur. E-posta, telefon ve kredi kartı desenleri regex ile tespit edilip [REDACTED] ile değiştirilir. Maskeleme toplama aşamasında yapılmalıdır; merkezi depoda düz metin kişisel veri birikmesi yasal risk oluşturur.

Dashboard ve görselleştirme

Grafana, metrik ve log sorgularını birleştiren dashboard'lar sunar. Her servis için altın sinyal (golden signals) dashboard'u tanımlanmalıdır: latency, traffic, errors, saturation. Dashboard'lar kod olarak versiyonlanır; Grafana provisioning ile Git'ten otomatik yüklenir. Manuel oluşturulan dashboard'lar kişiye bağımlı kalır ve kaybolabilir.

On-call ekibinin ilk bakacağı "system overview" dashboard'u, tüm kritik servislerin SLO durumunu tek ekranda göstermelidir. Kırmızı panel görüldüğünde drill-down ile ilgili servis detayına geçilir.

Olay müdahalesinde gözlemlenebilirlik

Olay anında log arama sorguları önceden hazırlanmış olmalıdır. "Son 15 dakikada 5xx dönen istekler", "Belirli trace ID'nin tüm span'leri", "Veritabanı bağlantı hatası içeren loglar" gibi kayıtlı sorgular runbook'a eklenir. Stres altında ad hoc sorgu yazmak zaman kaybettirir.

Post-incident review'da observability boşlukları değerlendirilir: "Bu hatayı neden 10 dakika geç fark ettik?" sorusunun cevabı genellikle eksik metrik veya gürültülü alarmdır. Her olay sonrası en az bir observability iyileştirme maddesi backlog'a eklenir.

Doğru kurgulanmış bir gözlemlenebilirlik yığını, dağıtık sistemlerin karmaşıklığını yönetilebilir kılar. Log ve metrik toplama yatırımı, olay müdahale süresini ve müşteri etkisini doğrudan azaltır.