1. GİRİŞ

Kubernetes tabanlı platformlarda izleme (monitoring) yalnızca metrik toplamak değildir; performans, güvenlik, maliyet ve kullanıcı deneyimi hedeflerini destekleyen uçtan uca bir gözlemlenebilirlik (observability) stratejisidir. Mikroservislerin dağıtık doğası, ephemeral altyapı ve yüksek dinamiklik geleneksel izleme yaklaşımlarını yetersiz kılar. Bu nedenle modern Kubernetes monitoring pratikleri, metrik (metrics), günlük (logs) ve iz (traces) üçlüsünü entegre ederek hızlı teşhis, otomasyon ve SLO temelli operasyon sağlayacak şekilde tasarlanmalıdır.

Neden bugün önemli?

• Dağıtık sistemlerde problem tespiti daha zor: tek bir servis hatası sistem çapında etkiler yaratabilir.
• Bulut maliyetleri ve SLA gereksinimleri, kaynak kullanımının izlenmesini zorunlu kılıyor.
• AI/ML ve gerçek zamanlı iş yükleri, daha hassas ve düşük gecikmeli telemetry gerektiriyor.

Kimler için önemli?

• Platform mühendisleri, SRE ve DevOps ekipleri
• Geliştiriciler — servisleri instrument etme sorumluluğu olan ekipler
• Güvenlik ve uyumluluk ekipleri — audit ve anomaly detection için telemetry gerekir

Hangi problemleri çözüyor?

• İzlenebilirlik eksikliğini giderme ve root cause analysis süresini kısaltma
• Otomatik alerting ve on‑call yükünün azaltılması
• Performans darboğazlarını, maliyet anomalilerini ve güvenlik olaylarını zamanında fark etme

2. KAVRAMSAL TEMELLER

2.1 Observability vs Monitoring

Monitoring genelde metriklerin toplanması ve alerting ile ilgilidir; observability ise sistemin iç durumunu anlayabilmek için gerekli veriyi (metrics, logs, traces) sağlayan ve bu veriyi ilişkilendirerek sorunun nedenini ortaya koyan daha geniş bir disiplindir. Observability, black‑box sistemlerinin davranışını açıklayabilmeyi hedefler.

2.2 Temel bileşenler

• Metrics: Zaman serisi veriler; CPU, memory, request latency, error rate vb.
• Logs: Olay bazlı, serileştirilmiş veya yapılandırılmış mesajlar; debug ve audit için gereklidir.
• Traces: Dağıtık izleme; bir isteğin servisler arası yolculuğunu gösterir (span, trace id).
• Instrumentation: Uygulama koduna konulan metrik/trace/log çağrıları (OpenTelemetry, client libs).

2.3 Terminoloji

• Cardinality: Metriklere eklenen label sayısı; yüksek cardinality hem esneklik hem de maliyet getirir.
• Retention: Telemetry verisinin saklanma süresi.
• Sampling: Yüksek hacimli trace/log verilerini azaltma tekniği.
• SLI / SLO / SLA: Service Level Indicator, Objective ve Agreement — izleme hedeflerinin iş ile hizalanması için kullanılır.

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

3.1 Uygulama tarafı (Instrumentation)

Uygulamalar OpenTelemetry veya Prometheus client kütüphaneleri ile instrument edilir. Metrikler genelde uygulama seviyesinde (request latency, queue length), framework seviyesinde (HTTP server metrics) ve altyapı seviyesinde (pod CPU/mem) toplanır. Tracing için span'lar oluşturulur; her span’in trace id ile ilişkilendirilmesi root cause analysis'i kolaylaştırır. Log'lar structured format (JSON) ile gönderilmeli, trace id ve request id gibi bağlayıcı etiketlerle zenginleştirilmelidir.

3.2 Toplayıcılar ve pipeline

Metrikler genelde Prometheus tarafından scrape edilir. Loglar fluentd/FluentBit ile toplanıp Elasticsearch/Opensearch veya cloud log sink'lerine gönderilir. Trace'ler OpenTelemetry Collector veya Jaeger/Zipkin backend'ine gönderilir. OpenTelemetry Collector, ingestion, processing, sampling ve export adımlarını birleştiren merkezi bir bileşen olarak öne çıkar.

3.3 Storage ve sorgulama

Metrics: Prometheus TSDB veya uzak store (Thanos, Cortex) kullanılır. Logs: Elasticsearch/Opensearch, Loki gibi zaman serisi‑odaklı log çözümleri. Traces: Jaeger, Tempo veya managed APM servisleri. Long‑term retention için cost‑efficient object storage (S3/GS/Azure Blob) ile cold storage stratejileri uygulanmalıdır.

3.4 Correlation ve context propagation

Tracing ve logs arasında korelasyon için trace id/request id kullanımı zorunludur. OpenTelemetry context propagation HTTP headers (traceparent) üzerinden servisler boyunca taşınır ve tüm telemetry parçaları tek bir istek bağlamında ilişkilendirilebilir.

4. POPÜLER ARAÇLAR VE MİMARİLER

4.1 Prometheus + Grafana

Prometheus uygulama ve node metriklerini çekme (scrape) modeliyle çalışır. Grafana görselleştirme ve dashboard'lama için standart araçtır. Büyük ortamlarda ölçeklenebilirliği sağlamak için Thanos veya Cortex ile federation veya long‑term storage entegrasyonu yapılır.

4.2 OpenTelemetry

OpenTelemetry, metrics, traces ve logs için vendor‑agnostic bir instrumentation standardıdır. Collector ile veriyi birleştirir, sampling ve processing adımlarını merkezi hale getirir. Son yıllarda APM ve tracing dünyasında birleştirici bir katman olarak hızla benimsendi.

4.3 Logging stack (FluentBit/Fluentd → Elasticsearch/Opensearch / Loki)

FluentBit hafif collector olarak node'larda çalışırken Fluentd daha zengin işleme için kullanılır. Log storage olarak Elasticsearch/Opensearch yaygındır; Loki ise Grafana ile daha düşük maliyetli, label‑oriented log arama sağlar.

4.4 Tracing backends (Jaeger, Tempo, Zipkin)

Jaeger tracing, distributed tracing ve root cause analysis için popülerdir. Tempo (Grafana Labs) minimal dependency ile scaling için tercih edilir. Traces genelde yüksek hacimli olduğundan sampling stratejileri ve storage optimizasyonu zorunludur.

4.5 eBPF tabanlı observability (Cilium/Hubble, Pixie)

eBPF, kernel seviyesinde veri toplayarak düşük‑latency ve yüksek‑kapsamlı telemetry sağlar. Cilium/Hubble ile ağ akışları, Pixie ile application level tracing ve debug eBPF ile mümkün hale geliyor. eBPF observability, özellikle network ve syscall seviyesinde görünürlük gerektiğinde güçlüdür ancak kernel ve platform uyumluluğu gerektirir.

5. GERÇEK DÜNYA UYGULAMALARI

5.1 Netflix — Gözlemlenebilirlik kültürü

Netflix'in observability yaklaşımları, yüksek frekanslı telemetry, chaos engineering ve geniş monitoring altyapısı ile incident'leri hızlıca tespit edip müdahale etmesine olanak sağlar. Metriklerin iş ile eşlenmesi (business metrics) kritik önemdedir.

5.2 Uber — High cardinality ve sampling stratejileri

Uber, yüksek cardinality metrik yönetimi ve sampling stratejileri ile büyük boyutlu distributed tracing'le başa çıkmıştır. Örnekler, label kullanımını sınırlama ve bağlı çözümlerle veriyi normalize etme yönündedir.

5.3 Amazon / AWS — Managed monitoring

AWS CloudWatch, X‑Ray ve managed Prometheus çözümleriyle telemetry toplama ve analiz sağlar. Managed çözümler operational overhead'i azaltır ancak esneklik ve maliyet trade‑off'ları vardır.

5.4 OpenAI — Model observability

Model serving süreçlerinde latency, throughput ve model‑level metrics (request distribution, skew, drift) izlenir. Traces ile GPU kullanım pattern'leri ve data pipeline bottleneck'leri tespit edilir.

5.5 Stripe — SLO temelli monitoring

Fintech firmaları SLO odaklı izleme yapar; error budget'ler, alerting threshold'ları ve on‑call playbook'lar SLO'larla ilişkilendirilir. Bu yöntem, alert storm ve false positive'leri azaltır.

6. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Proaktif problem tespiti ve hızlı müdahale
• SLO/SLA bazlı operasyon ile iş hedefleriyle hizalanmış izleme
• Otomasyon (auto‑remediation, alert suppression) ile on‑call yükünü azaltma

Sınırlamalar

• Telemetry verisi maliyetli olabilir; retention ve cardinality planlaması gerektirir
• Yanlış instrumentasyon veya yetersiz correlation root cause analysis'i zorlaştırır
• eBPF gibi ileri tekniklerin işletimsel uyumluluğu ve güvenlik etkileri olabilir

7. ALTERNATİFLER VE KARŞILAŞTIRMA

8. EN İYİ PRATİKLER

Production için tavsiyeler

• SLI/SLO tanımları yapın ve izlemeyi bu hedeflere göre tasarlayın.
• Instrumentation'ı kademeli ve test edilmiş şekilde uygulayın: metrics, structured logs, trace context propagation.
• OpenTelemetry Collector kullanarak ingest pipeline'ınızı merkezi hale getirin; sampling, filtering ve routing burada yapılmalıdır.
• Retention politikalarını, veri sınıfına göre (hot/warm/cold) belirleyin ve maliyet planlaması yapın.

Performans ve maliyet optimizasyonu

• Metric label kullanımını sınırlayın; yüksek cardinality etiketler yerine aggregasyon stratejileri düşünün.
• Trace sampling ve tail‑sampling kombinasyonları ile kritik trace'leri saklayın, diğerlerini örnekleyin.
• Log seviyelerini ve sampling'i production için optimize edin; debug seviyesini yalnızca gerekli durumlarda aktif edin.

Security ve compliance

• Telemetry verilerinde hassas veri (PII, secrets) bulunmadığından emin olun; redaction ve PII scanning uygulayın.
• Telemetry erişimlerini RBAC ile sınırlandırın ve audit log'larını saklayın.

9. SIK YAPILAN HATALAR

• High cardinality metriklerin kontrolsüz kullanımı — maliyet patlamaları ve query yavaşlaması.
• Logs ve traces arasında bağlayıcı id'lerin olmaması — korelasyon yapılamaması.
• Alert fatigue — çok fazla ve yanlış yapılandırılmış alarm ekipleri yorar.
• Retention kuralları olmayan uzun süreli veri saklama — maliyet artışı.

10. GELECEK TRENDLER

1. AI‑assisted observability: Anomali tespiti, root cause önerileri ve otomatik runbook'lar ML ile desteklenecek.
2. eBPF ve kernel‑level telemetry: Daha az overhead ile daha derin veri elde edilecek; ağ ve syscall gözlemlenebilirliği artacak.
3. Unified telemetry standards: OpenTelemetry'nin olgunlaşmasıyla vendor‑agnostic, taşınabilir instrumentation yaygınlaşacak.
4. Cost‑aware monitoring: Monitoring çözümleri maliyet‑performans optimizasyonlarını otomatik önerip uygulayacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Prometheus mu yoksa managed monitoring mi tercih etmeliyim?

   Small–medium ekipler için Prometheus + Grafana ekonomik ve esnek bir çözümdür. Büyük ölçek veya düşük operasyonel yük isteyenler managed APM/monitoring hizmetlerini tercih edebilir; ancak maliyet ve vendor lock‑in trade‑off'u unutmayın.

2. 2. OpenTelemetry neden kullanmalıyım?

   OpenTelemetry vendor‑agnostic, unified instrumentation sağlar. Metrics, logs ve traces'i tek standarda bağlayarak taşıyıcı bağımsız yapı kurmanızı kolaylaştırır.

3. 3. Trace sampling'i nasıl ayarlamalıyım?

   Başlangıç olarak head‑based sampling ile yüksek trafikleri örnekleyin; tail‑sampling ile hatalı veya yüksek‑latency trace'leri saklayın. Kritik iş akışları için deterministik sampling kuralları belirleyin.

4. 4. Metrik cardinality'yi nasıl kontrol ederim?

   Label sayısını sınırlayın, yüksek‑cardinality label'ları agregasyon katmanına taşıyın ve gerektiğinde histogram veya summary tiplerini kullanın.

5. 5. Logs ve traces'i nasıl korele ederim?

   Her request için benzersiz bir trace id/request id oluşturun ve bu id'yi log'lara ve trace span'larına ekleyin. OpenTelemetry context propagation bu bağlamı taşımada yardımcı olur.

6. 6. eBPF observability ne zaman tercih edilmeli?

   Network troubleshooting, syscall seviyesinde görünürlük veya yüksek performans gerektiren monitoring senaryolarında eBPF etkili olur. Ancak kernel uyumluluğu ve güvenlik değerlendirmesi yapılmalı.

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

   İş hedeflerine göre SLI'lar (latency, availability, error rate) seçin. SLO'lar tutarlı, ölçülebilir ve uygulama ekipleri tarafından anlaşılır olmalıdır. Error budget'leri operasyon kriterlerine bağlayın.

8. 8. Monitoring maliyetlerini nasıl yönetirim?

   Retention, sampling, aggregation ve cold storage stratejileri uygulayın. Ayrıca metrics, logs ve traces için ayrı maliyet merkezleri belirleyin ve alert'lerle anormal maliyet artışını izleyin.

Anahtar Kavramlar

Observability

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

Prometheus

Metrics toplama ve sorgulama için yaygın kullanılan zaman serisi veritabanı ve scrape modeli.

OpenTelemetry

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

Trace

Dağıtık bir isteğin tüm servisler arası yolculuğunu temsil eden span'lar dizisi.

eBPF

Kernel seviyesinde programlama imkânı sağlayarak yüksek performanslı observability ve security sağlar.

Öğrenme Yol Haritası

1. 0–1 ay: Prometheus ve Grafana kurulumunu yapın; temel metrikleri (CPU, memory, pod ready) dashboard'layın.
2. 1–3 ay: OpenTelemetry ile uygulamaları instrument edin; traces ve structured logs ekleyin; basit alert'ler oluşturun.
3. 3–6 ay: Thanos/Cortex ile long‑term metrics storage, Jaeger/Tempo ile tracing scale, ve FluentBit + Elasticsearch/Loki ile log pipeline kurun.
4. 6–12 ay: SLO odaklı izleme, eBPF tabanlı observability denemeleri, cost optimization ve AI destekli anomaly detection projeleri üzerinde çalışın.