1. GİRİŞ

Observability (gözlemlenebilirlik) modern yazılım mühendisliğinin merkezi bir konusu hâline geldi. Mikroservisler, sunucusuz (serverless) platformlar, container‑orchestration ve dağıtık sistemler uygulama davranışını tek bir noktadan anlamayı zorlaştırdı. Bu ortamda yalnızca metric toplamak yeterli değil; logs, traces ve metrics'in birlikte korelasyonu gereklidir. Observability Architecture, telemetri toplama, işleme, depolama ve sorgulama hattının (telemetry pipeline) tasarlanmasıdır. Bu makale, üretim grade bir observability mimarisini teknik detaylarıyla ele alır: neden önemli, temel bileşenler, veri akışı, ölçekleme, güvenlik, örnek uygulamalar ve en iyi uygulamalar.

Neden bugün önemli?

• Dağıtık uygulamalar karmaşık hata nedenleri üretir; root cause analysis (RCA) için birleşik telemetri gerekir.
• SLA/SLO yönetimi, veri‑temelli operasyon kararları ve incident response süreçleri observability ile mümkün olur.
• OpenTelemetry ve standart protokoller sayesinde vendor‑agnostic, taşınabilir gözlemlenebilirlik çözümleri oluşturmak daha kolay.

Kimler için önemli?

• SRE ve platform mühendisleri — servis sağlığını, kapasitasyon ve maliyeti yönetmek için.
• Backend/frontend geliştiriciler — performans sorunlarını hızlıca teşhis etmek isteyenler.
• CTO ve teknoloji yöneticileri — operasyonel metriklerle iş kararlarını bağlamak isteyenler.

Hangi problemleri çözüyor?

• Incident süresini kısaltma (MTTR azaltma)
• SLO odaklı uyarı sistemiyle yanlış pozitif/negatif uyarıları azaltma
• Kapasite planlama ve performans optimizasyonu için veri sağlama

2. KAVRAMSAL TEMELLER

2.1 Observability ve monitoring farkı

Monitoring genelde belirli metriklerin veya uyarıların takibi iken observability, sistemin iç durumunu anlamak için yeterli içgörü sağlayan telemetri setine sahip olma yetisidir. Observability; metrics, logs ve traces'in birlikte kullanılmasını, doğru modelleme ve bağlam (context) ile korelasyonu içerir.

2.2 Temel bileşenler

• Instrumentation: Uygulamaya eklenen SDK ve library'ler (OpenTelemetry) — metrics, traces, logs üretimi.
• Collectors / Agents: Telemetriyi toplayan ve ileriye gönderen prosesler (OTel Collector, Fluentd, Vector).
• Telemetry Pipeline: Collection → Processing → Enrichment → Export adımlarını içeren veri hattı.
• Storage Backends: Metrics store (Prometheus/Cortex/Thanos), logs store (Loki/Elasticsearch), traces store (Tempo/Jaeger/Zipkin).
• Query & Visualization: Grafana, Kibana, custom UIs.

2.3 Terminoloji

• Cardinality: Metrik ve etiket (label) kombinasyonlarının sayısı — yüksek cardinality maliyet getirir.
• Sampling: Trace veya log alt kümesi alma stratejileri (head/tail‑based sampling).
• Aggregation: Metric verisini bucket'lama/histogram ile özetleme (p95, p99 gibi percentil hesapları).

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

3.1 Yüksek seviyeli sistem mimarisi

Observability mimarisi tipik olarak şu katmanlardan oluşur: Instrumentation (SDK), Collection (agents/collectors), Processing/Enrichment (OTel Collector pipeline), Storage (timeseries, logs, traces), Query & Visualization. Ayrıca alerting, anomaly detection ve SLO engine'leri (Prometheus Alertmanager, Cortex Alerting, SLO tools) bu akışa entegre edilir.

3.2 Instrumentation — OpenTelemetry merkezili yaklaşım

OpenTelemetry (OTel) bugün en yaygın standarddır. SDK'lar metrics, traces ve logs üretir; context propagation (trace context) distributed tracing'in temelini oluşturur. Uygulamaya uygun seviyede enstrümantasyon (manual vs auto‑instrumentation) seçilmeli: kritik path'lerde manual spans ve meaningful attributes eklenmelidir.

3.3 Collectors ve agents

Collector'lar telemetriyi application'dan alır, filter, enrich ve örnekleme yaparak storage backend'lere gönderir. OTel Collector, vendor‑agnostic pipeline kurmak için idealdir. Edge‑side agent (node level) ile sidecar collector (pod level) kombinasyonu kullanılabilir. Önemli noktalar:

• Filter ve redact işlemleri (PII masking) collector aşamasında yapılmalı.
• Local buffer ve retry mekanizmaları network kesintilerinde veri kaybını azaltır.

3.4 Processing & Enrichment

Telemetri veri akışında context enrichment (ör. deploy metadata, service owner, SLO tag'leri) yapılmalıdır. Bu, incident esnasında daha hızlı yönlendirme ve root cause analysis sağlar. Ayrıca sampling kararları ve re‑routing (hot data → fast store, cold data → archival) bu katmanda alınır.

3.5 Storage Backends

Metrics: Prometheus paradigması kısa süreli scrape ve TSDB saklama için uygundur. Large scale için Cortex veya Thanos gibi dağıtık, uzun‑retention çözümleri gerekir.
Logs: Centralized log store (Elasticsearch, Loki, ClickHouse veya cloud offerings) yüksek ingest ve sorgu gereksinimleri için optimize edilmelidir.
Traces: Tempo, Jaeger, Zipkin veya commercial APM çözümleri; traces yüksek boyutlu veri olduğundan sampling ve indexing stratejileri önemlidir.

3.6 Query, Dashboards ve Alerting

Grafana, Kibana veya APM UI'ları ile dashboard'lar oluşturulur. Alerting kuralları SLO bazlı olmalıdır — doğrudan raw metric eşiklerine dayanan alarmlar yanlış tetikleyebilir. Alertmanager ve SLO tooling ile error budget kullanımına göre otomatik aksiyonlar planlanabilir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix — veri odaklı RCA ve araç takımı

Netflix yüksek trafikli sistemlerde observability'i operasyonel karar mekanizmasına entegre etmesiyle bilinir. Tracing ile hot‑path analizleri, metrics ile capacity planning, logs ile detaylı hata analizi bir arada kullanılır.

4.2 Uber — yüksek cardinality ve event‑driven telemetri

Uber gibi firmalar, yüksek cardinality etiketlerle çalışırken verimlilik için özel ingestion ve storage optimizasyonları geliştirmiştir. Event‑based telemetri, metric dimensions'un artmasına rağmen kabul edilebilir maliyetle çalışacak şekilde tasarlanmıştır.

4.3 Stripe / Fintech — SLO odaklı izleme

Fintech firmaları için SLO'lar iş kritiktir. Observability mimarileri, business metric'leri teknik metriklerle korele ederek SLA uyumluluğunu sağlar ve otomatik mitigasyon akışları sunar.

4.4 Cloud provider managed solutions

AWS CloudWatch, Azure Monitor, Google Cloud Operations managed çözümler sunar. Hızlı başlangıç için uygundur; fakat vendor‑lockin ve fiyat/performans analizleri gerekir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Hızlı RCA: traces + logs + metrics korelasyonu incident çözüm süresini kısaltır.
• SLO/alerting ile noise azaltılır ve operasyonel kararlar netleşir.
• Kapasite ve maliyet optimizasyonuna veri sağlar.

Sınırlamalar

• Maliyet: yüksek ingest, storage ve query maliyetleri; veri retention planları gerekir.
• Veri yönetimi karmaşıklığı: high cardinality control, sampling ve aggregation tasarımı uzmanlık ister.
• Gizlilik: log ve trace içeriğinde PII olabilir; masking ve redaction gerekir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• SLO‑first yaklaşım: önce 1–3 kritik SLO belirleyin, metric ve alertleri SLO'ya dayandırın.
• OpenTelemetry ile uygulamayı instrument edin ve context propagation'u zorunlu kılın.
• Collector'ları pipeline merkezinde tutun; filter, redact, enrich işlemlerini merkezi yapın.

Performans optimizasyonu

• High cardinality etiketleri sınırlandırın; label eksfiltration riskini ve maliyeti azaltın.
• Trace sampling stratejilerini (head/tail/method) kullanın; canary tracing veya high‑error tracing için özel kurallar koyun.
• Metrics aggregation (histograms, summaries) ile p95/p99 hesaplamalarını optimize edin.

Güvenlik

• PII içeren logları maskalayın, otomatik redaction kuralları uygulayın.
• Telemetry pipeline erişimlerini sıkı RBAC ile yönetin; collectors ve storage hizmetlerine ayrı yetkiler tanımlayın.

Ölçeklenebilirlik

• Cold/hot storage stratejisi uygulayın: recent data hızlı sorgulanır, older data daha ucuz saklama katmanına taşınır.
• Distributed TSDB (Cortex/Thanos) ile long‑term retention sağlayın; sorgu latency'lerini optimize edin.

8. SIK YAPILAN HATALAR

• Her etiketi metriklere eklemek (cardinality explosion).
• Alertleri ham metric eşiklerine dayandırmak — SLO/ürün odaklı alarm yok.
• Collector seviyesinde PII redaction yapmamak — gizlilik ihlallerine açık olmak.
• Telemetry'i test etmeden production'a geçmek — yanlış tracing context ve eksik spans.

9. GELECEK TRENDLER

1. Observability as Data: Telemetry verisinin ML modelleriyle işlenmesi, anomaly detection ve öngörücü bakımın (predictive maintenance) artışı.
2. eBPF tabanlı yerinde izleme: Kernel seviyesinde daha doğru ve düşük overhead telemetri toplama yaygınlaşacak.
3. AI destekli RCA: Telemetry korelasyonu ve root cause analysis için otomatik öneriler artacak.
4. Standardization: OpenTelemetry olgunlaştıkça vendor‑agnostic, taşınabilir observability çözümleri daha yaygın olacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Observability'e nereden başlamalıyım?

   Önce kritik SLO'ları belirleyin, OpenTelemetry ile uygulamayı instrument edin ve temel metrics + traces + logs pipeline'ı kurun. Ardından alert ve dashboard'ları SLO'ya göre şekillendirin.

2. 2. High cardinality sorununu nasıl yönetirim?

   Label seçiminde dikkatli olun; user‑id gibi yüksek cardinality etiketleri metrics'te değil traces/logs'ta tutun. Aggregation ve rollup stratejileri kullanın.

3. 3. Sampling stratejisi nasıl olmalı?

   Başlangıç için tail‑based sampling önerilir (hata olan veya yüksek latency traces'i önceliklendirir). Yük arttıkça head‑based veya adaptive sampling kombinasyonları kullanılmalıdır.

4. 4. OpenTelemetry neden tercih edilmeli?

   Vendor‑agnostic olması, standart protokoller (OTLP) ve geniş SDK desteği sayesinde taşınabilir ve sürdürülebilir observability sağlar.

5. 5. Metrics retention maliyetini nasıl kontrol ederim?

   Retention politikaları, aggregation (downsampling), cold storage ve cardinality yönetimi ile maliyeti kontrol altına alabilirsiniz.

6. 6. Traces ve logs ilişkilendirmesini nasıl yaparım?

   Trace context ve span id'lerini loglara inject ederek korelasyon sağlayın; bu, bir alert geldiğinde ilgili trace ve log'ları otomatik bulmayı kolaylaştırır.

7. 7. Observability'i güvenli hale getirmek için ne yapmalıyım?

   Telemetry verisini encrypt edin, PII masking uygulayın, collectors access'ini RBAC ile sınırlayın ve audit log'larını SIEM'e gönderin.

8. 8. Hangi araçlarla başlamalıyım?

   OpenTelemetry (instrumentation), Prometheus (metrics), Grafana (viz), Loki (logs) ve Tempo/Jaeger (traces) kombinasyonu iyi bir başlangıç setidir.

Anahtar Kavramlar

Telemetry

Metrics, logs, traces gibi uygulama ve sistem davranışını gösteren veriler.

OpenTelemetry

Vendor‑agnostic observability standardı ve SDK/collector ekosistemi.

Cardinality

Metrik etiket kombinasyonlarının sayısı; yüksek cardinality maliyet ve performans sorunları yaratır.

Sampling

Trace veya log kümelerinin örneklenmesi; maliyet/kapasite dengesini sağlar.

SLO

Service Level Objective — servis için hedeflenen performans/güvenilirlik seviyesi.

Öğrenme Yol Haritası

1. 0–1 ay: Metrics, logs, traces temellerini öğrenin; küçük bir uygulamayı OpenTelemetry ile instrument edin.
2. 1–3 ay: Prometheus + Grafana ile metric collection ve dashboard kurun; basic alerting ekleyin.
3. 3–6 ay: Tracing (Jaeger/Tempo), log aggregation (Loki/Elasticsearch) ve korelasyon teknikleri üzerinde çalışın; SLO'lar tanımlayın.
4. 6–12 ay: Large scale ingestion, sampling stratejileri, cost optimization ve AI destekli anomaly detection projelerinde deneyim kazanın.