1. GİRİŞ

Modern dağıtık sistemler ve mikroservis mimarileri, uygulama davranışının anlaşılmasını zorlaştırdı. Kubernetes gibi dinamik orkestrasyon platformlarında sorunları çözmek için sadece logs toplamak yeterli değildir; metrics, logs ve traces üçlüsünü birbirine bağlayan kapsamlı bir observability stratejisi gereklidir. Bu makale, Kubernetes observability'nin teknik temellerini, veri akışını, popüler araçları, gerçek dünya uygulamalarını ve production için uygulanabilir en iyi yöntemleri ayrıntılı biçimde ele alır.

Neden bugün önemli?

• Dağıtık çağrı zincirleri, latency ve hataların kök nedenini izole etmeyi zorlaştırıyor.
• Cloud maliyet optimizasyonu ve SLO/SLA yönetimi iş hedeflerine doğrudan bağlı.
• AI/ML ve gerçek‑zamanlı uygulamaların artan talebi, daha hassas ve zamanında telemetry gerektiriyor.

Kimler için önemli?

• Platform mühendisleri ve SRE ekipleri
• Backend geliştiriciler ve MLOps mühendisleri
• Güvenlik ve uyumluluk ekipleri

Hangi problemleri çözüyor?

• İnce ayarlı alerting ve hızlı root cause analysis
• Otomatik remediation ve observability destekli otomasyon
• Maliyet görünürlüğü ve performans optimizasyonu

2. KAVRAMSAL TEMELLER

2.1 Observability nedir?

Observability, sistemin içsel durumunu dışarıdan toplanan veri ile anlayabilme kapasitesidir. Bu, metrics (sayısal zaman serileri), logs (olay kayıtları) ve traces (dağıtık izleme) ile sağlanır. Önemli olan bu veri türlerini birbirine bağlayarak tek bir olayın nedenini hızlıca tespit edebilmektir.

2.2 Temel bileşenler

• Metrics: CPU, memory, request latency, error rate gibi sayısal göstergeler.
• Logs: Yapılandırılmış (JSON) loglar sorun tahlili ve audit için gereklidir.
• Traces: Bir isteğin mikroservisler arasındaki yolculuğunu gösterir; span ve trace id'leri ile korelasyon sağlar.
• Events / Alerts: Anomali veya SLO ihlali durumunda üretilen bildirimler.

2.3 Terimler ve yaklaşımlar

• Instrumentation: Uygulamaya eklenen metrik, log ve trace çağrıları.
• Context propagation: Trace id veya request id'nin servisler arasında taşınması.
• Sampling: Trace hacmini kontrol etmek için örnekleme stratejileri.
• Cardinality: Metrics'e eklenen label sayısı; yüksek cardinality maliyet ve sorgu karmaşıklığını artırır.

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ, VERİ AKIŞI VE KOMPOZİSYON

3.1 Instrumentation ve OpenTelemetry

OpenTelemetry, metrics, traces ve logs için vendor‑agnostic bir standart ve SDK seti sağlar. Uygulama koduna OpenTelemetry SDK'ları eklenir; HTTP middleware, database client wrapper ve custom span'lar ile izleme verisi üretilir. Context propagation (traceparent gibi header'lar) sayesinde bir isteğin tüm yaşam döngüsü izlenebilir hale gelir.

3.2 Collector ve ingest pipeline

OpenTelemetry Collector, telemetri verisini toplayıp işlemeye, sample etmeye ve farklı backendlere export etmeye yarayan merkezi bir bileşendir. Collector; batching, retry, filtering, attributes dönüştürme (enrichment), tail‑sampling gibi adımları yönetir. Collector'ları cluster içinde daemonset veya sidecar olarak konumlandırabilirsiniz; merkezi collector'lar edge‑deneticiyi azaltmak için tercih edilir.

3.3 Storage ve query katmanı

- Metrics: Prometheus (local TSDB) ve ölçek için Thanos/Cortex/ Mimir gibi çözümler.\n - Logs: Elasticsearch/Opensearch, Loki (Grafana Labs) veya cloud log sinks.\n - Traces: Jaeger, Tempo veya managed APM servisleri.\n Uygun retention stratejileri, hot/warm/cold katmanlama ve maliyet‑performans dengesi planlanmalıdır.

3.4 Correlation — metrics, logs ve traces'i birleştirmek

Korelasyon için en az şunlar gerekir: request id/trace id'nin loglara eklenmesi, metrics etiketlerinde kritik bilgilerin bulunması ve tracing ile log platformunun birbirine referans vermesi. Bu sayede bir latency artışını, ilgili traces ile takip edip, log'larda yer alan hata mesajlarına hızlıca ulaşabilirsiniz.

3.5 eBPF ve kernel‑level observability

eBPF, kernel seviyesinde network, syscall ve performans verisi toplayarak yüksek doğrulukta observability sağlar. Pixie, Cilium/Hubble veya custom eBPF programları ile latency, socket-level interactions ve container context performansı gözlemlenebilir. eBPF kullanımı kernel uyumluluğu ve güvenlik incelemesi gerektirir.

4. POPÜLER ARAÇLAR, TASARIM ÖRÜNTÜLERİ VE ENTEGRASYONLAR

4.1 Prometheus ekosistemi

Prometheus, Kubernetes'te metrics toplamanın defacto standardıdır. Node exporter, kube‑state‑metrics, uygulama client'ları ve Pushgateway gibi bileşenlerle zengin bir ekosistem sunar. Thanos veya Cortex ile dağıtık ve long‑term storage sağlanabilir.

4.2 OpenTelemetry + Jaeger / Tempo

OpenTelemetry ile üretilmiş trace'ler Jaeger veya Tempo'ya gönderilir. Tempo, storage olarak object store (S3 gibi) kullanarak maliyet etkin long‑term retention sağlar. OpenTelemetry Collector, trace sampling ve enrichment için merkezi nokta sunar.

4.3 Logging çözümleri

FluentBit/Fluentd node seviyesinde log toplama, Elasticsearch veya Loki gibi backend'lere gönderme yaygın bir mimaridir. Loki, label‑oriented arama ile promethues benzeri bir yaklaşım sunar ve Grafana ile kolay entegrasyon sağlar.

4.4 eBPF tabanlı araçlar

Cilium/Hubble ağ gözlemlenebilirliği ve politika enforcement; Pixie uygulama seviyesinde otomatik tracing ve debug sağlar. Bu araçlar, network ve syscall seviyesinde housekeeping yapmadan derin görüş sağlar.

4.5 Managed APM ve bulut servisleri

Datadog, New Relic, AWS X‑Ray, Azure Monitor gibi managed çözümler hızlı kurulum ve entegre alerting sağlar. Ancak maliyet ve vendor lock‑in dikkate alınmalıdır.

5. GERÇEK DÜNYA KULLANIM ÖRNEKLERİ

5.1 Netflix — SLO odaklı observability

Netflix, business‑aligned metrikler ve SLO'lara odaklanarak observability stratejisini işletir. High cardinality metrikleri kontrollü kullanır, alerting'i error budget'e bağlar ve chaos testing ile gözlemlenebilirliği doğrular.

5.2 Uber — Yüksek cardinality ve sampling

Uber, çok yüksek trafik ve cardinality nedeniyle özel sampling stratejileri ve veri normalizasyonu uygular. Trace'leri tail‑sampling ile kritik durumlarda saklar; metrics aggregation ile storage maliyetini düşürür.

5.3 Amazon/AWS — Managed ve hibrit stratejiler

AWS üzerinde Prometheus kompatibilitesi, CloudWatch ve X‑Ray entegrasyonu ile hybrid observability çözümleri yaygındır. Managed çözümler operasyonel yükü azaltır ancak maliyet kontrolü ve veri kontrolü planlanmalıdır.

5.4 OpenAI — Model ve data pipeline observability

Model serving pipeline'ları için latency, model drift, input distribution izlenir. Traces GPU kullanımını ve veri pipeline bottleneck'lerini ortaya çıkarır; detaylı telemetry ile model performansı ölçülür.

6. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Hızlı root cause analysis ve proaktif müdahale
• SLO odaklı operasyon ile iş hedeflerine uygun izleme
• Otomasyon tetikleme: auto‑remediation, rollback, scale‑up senaryoları

Sınırlamalar

• Maliyet: retention, yüksek cardinality ve trace hacmi maliyeti artırır
• Operational complexity: pipeline yönetimi, sampling politikaları ve veri doğrulama gerektirir
• Güvenlik ve gizlilik: telemetry içinde PII veya secret olmamalıdır; redaction politikaları gereklidir

7. ALTERNATİFLER VE KARŞILAŞTIRMA

8. EN İYİ PRATİKLER

Production kullanım

• SLI/SLO tanımları yapın ve monitoring'i bu hedeflere göre kurun.
• Instrumentation'ı kademeli ve test edilmiş şekilde uygulayın; trace / log correlation zorunlu olsun.
• OpenTelemetry Collector veya merkezi ingest pipeline ile veriyi normalize edin.
• Retention ve cold storage stratejisi ile maliyetleri yönetin.

Performans ve maliyet optimizasyonu

• Label cardinality'yi sınırlayın; her label eklemeden önce sorgulanabilirlik faydasını ölçün.
• Trace sampling, tail‑sampling ve aggregation kullanın; kritik iş akışlarını korun.
• Metric rollover ve downsampling stratejileri ile uzun dönem verisini saklayın.

Security ve governance

• Telemetry verisinde PII/secret olmadığından emin olun; redaction ve masking uygulayın.
• Telemetry erişimini RBAC ile sınırlandırın ve audit log'ları saklayın.
• Collector ve eBPF bileşenlerinin security review'dan geçtiğinden emin olun.

9. SIK YAPILAN HATALAR

• High cardinality metriklerin kontrolsüz kullanımı — maliyet ve query karmaşıklığı.
• Trace id eksikliği — logs, traces ve metrics arasında korelasyon sağlanamaması.
• Sampling stratejisi olmadan tüm trace'leri toplamak — storage patlaması.
• Alert fatigue: çok sayıda ve anlamlı olmayan alert'ler ekipleri yorar.

10. GELECEK TRENDLER

1. AI destekli observability: Anomali tespiti, RCA önerileri ve otomatik remediation için ML modelleri yaygınlaşacak.
2. eBPF'nin yükselişi: Kernel‑level telemetry daha erişilebilir hale gelecek; network ve syscall seviyesinde zengin veri sağlanacak.
3. Unified telemetry standards: OpenTelemetry olgunlaşarak vendor‑agnostic, taşınabilir observability'i standartlaştıracak.
4. Cost‑aware monitoring: Monitoring çözümleri otomatik olarak maliyet‑verimlilik optimizasyonu önerileri sunacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. OpenTelemetry neden kullanmalıyım?

   Vendor‑agnostic standart sağlar; metrics, traces ve logs'i tek bir modelde toplayıp farklı backendlere export etmenize imkân verir.

2. Trace sampling nasıl olmalı?

   Head‑based sampling ile yüksek hacimli trafik azaltılabilir; tail‑sampling ile hata ve yüksek latency içeren trace'ler saklanır. Kritik yollar için deterministik sampling tercih edin.

3. Metrics cardinality'yi nasıl kontrol ederim?

   Label sayısını azaltın, yüksek cardinality label'ları aggregasyon veya rollup seviyesine taşıyın ve histogram/summary tiplerini değerlendirin.

4. Logs ve traces arasında nasıl korelasyon kurarım?

   Global trace id veya request id üretip bunu tüm log ve trace span'larına ekleyin; OpenTelemetry context propagation bu süreci kolaylaştırır.

5. eBPF ne zaman tercih edilmeli?

   Network troubleshooting, syscall seviyesi debug veya performans analizi gerektiğinde eBPF tercih edilebilir; kernel uyumluluğu ve güvenlik gereksinimlerini göz önünde bulundurun.

6. Monitoring maliyetlerini nasıl azaltırım?

   Sampling, retention optimizasyonu, cold storage, aggregation ve cardinality kontrolü ile maliyetleri yönetin.

7. SLO'lar nasıl tanımlanmalı?

   İş hedefleriyle bağlantılı, ölçülebilir ve uygulanabilir SLI'lar seçin; error budget'leri operasyon kararlarına bağlayın.

8. Managed monitoring mi yoksa self‑hosted mi?

   Operasyonel kapasitenize ve maliyet toleransınıza göre karar verin. Küçük ekipler için managed çözümler hızlıdır; büyük ölçeklerde self‑hosted + scale çözümleri maliyet/verimlilik sağlar.

Anahtar Kavramlar

Observability

Metrics, logs ve traces ile sistem davranışını anlayabilme kapasitesi.

OpenTelemetry

Vendor‑agnostic instrumentation standardı ve collector ile telemetry pipeline yönetimi.

Trace

Dağıtık isteğin tüm servisler arası yolculuğunu gösteren span dizisi.

eBPF

Kernel seviyesinde programlanabilirlik sağlayarak yüksek performanslı telemetry toplama imkânı verir.

Cardinality

Metric label'larının toplam kombinasyon sayısı; yüksek cardinality yönetimi önemlidir.

Öğrenme Yol Haritası

1. 0–1 ay: Prometheus, Grafana kurulumu ve temel metrikler ile dashboard oluşturun.
2. 1–3 ay: OpenTelemetry SDK ile uygulamaları instrument edin; traces ve request id propagation'ı uygulayın.
3. 3–6 ay: Collector pipeline, sampling ve tail‑sampling stratejileri; logging stack ve Loki/Elasticsearch entegrasyonu kurun.
4. 6–12 ay: eBPF tabanlı observability, SLO yönetimi, long‑term storage ve AI destekli anomaly detection projeleri üzerinde çalışın.