Observability Stack Tasarımı

Bir sistem büyüdükçe “monitoring” tek başına yeterli olmaz. CPU ve RAM grafikleri, bir problemin varlığını gösterir; ama problemi neden yaşadığınızı söylemez. Observability yaklaşımı tam burada devreye girer.

Monitoring ile observability farkı

Monitoring genellikle “ne oldu?” sorusuna cevap verir. Observability ise “neden oldu, hangi serviste başladı ve kullanıcıyı nasıl etkiledi?” sorularını da yanıtlar.

Kurumsal yapılarda özellikle şu üç veri tipi birlikte düşünülmelidir:

• Metrics: Sunucu ve uygulama sayısalları
• Logs: Olay ve hata kayıtları
• Traces: İstek zincirinin servisler arası yolu

İdeal akış

Benim en çok tercih ettiğim tasarımda veri akışı şu şekilde ilerler:

1. Sunucu, uygulama ve ağ cihazları telemetri üretir.
2. OpenTelemetry Collector veriyi normalize eder.
3. Log, metric ve trace doğru depolama katmanlarına yönlenir.
4. Grafana üzerinden hepsi tek deneyimde sorgulanır.
5. Alarm sistemi incident sürecini tetikler.

Neden tek panel yaklaşımı önemli?

Bir uyarı geldiğinde ekip şunu yapmamalı:

• başka ekranda CPU grafiğine bak
• sonra başka araçta log ara
• sonra trace için üçüncü aracı aç

Bunun yerine tek alarmdan aynı olayın log, metric ve trace zincirine gidilebilmelidir. Bu, özellikle kritik servislerde MTTR süresini gözle görünür şekilde düşürür.

Pratik stack örneği

• Metrics için Prometheus veya Mimir
• Logs için Loki
• Traces için Tempo
• Dashboard için Grafana
• Collection için OpenTelemetry Collector

Bu yaklaşım hem açık kaynak dünyasında güçlüdür hem de maliyet kontrolü açısından esnektir.

receivers:
  otlp:
    protocols:
      grpc:
      http:

exporters:
  prometheusremotewrite:
    endpoint: http://mimir:9009/api/v1/push
  loki:
    endpoint: http://loki:3100/loki/api/v1/push

Alarm tasarımında yaptığım temel ayrım

• Semptom alarmı: kullanıcıyı etkileyen belirti
• Neden alarmı: kök sebebi işaret eden veri
• Kapasite alarmı: yaklaşan risk

Bu ayrım yapılmazsa ekip aynı olay için onlarca alarm alır ama hangisinin gerçekten önemli olduğunu ayıramaz.

Sonuç

Doğru observability tasarımı, sadece sistemleri izlemek değil, sistemleri anlamak için kurulur. Büyük yapılarda log, metric ve trace katmanını tek operasyon modeline bağlamak artık lüks değil, temel ihtiyaçtır.