1. GİRİŞ

"Ne ölçülmezse yönetilemez" prensibi yazılım mühendisliğinde olduğu kadar operasyon ve platform mühendisliğinde de temel bir gerçektir. Metrics systems (metrik sistemleri), uygulama ve altyapı davranışlarını sayısal olarak ifade eden zaman serisi verilerinin toplanması, işlenmesi, saklanması ve görselleştirilmesini kapsar. Bu veriler, sistem sağlığını izlemek, kapasite planlamak, SLO/SLI takibi yapmak ve otomatik kararlar almak için hayati öneme sahiptir. Bulut‑native mimarilerin, microservice dağıtımlarının ve yüksek frekanslı CI/CD süreçlerinin yaygınlaşmasıyla metriklerin doğru şekilde toplanması ve yönetilmesi kritik hale geldi.

Neden bugün konuşuluyor?

• Dağıtık sistemler ve mikroservisler nedeniyle gözlemlenebilirlik gereksinimleri arttı.
• SLO/SLI odaklı operasyon, operasyonel riskleri metriklerle bağlamayı zorunlu kılıyor.
• OpenTelemetry, Prometheus gibi standartlar ve ölçeklenebilir open‑source çözümler metrik mimarilerini erişilebilir kıldı.

Kimler için önemli?

• SRE ve platform mühendisleri — operasyonel sağlık, kapasite, maliyet yönetimi için.
• Backend geliştiriciler — performans darboğazlarını belirlemek ve optimizasyon için.
• CTO ve ürün yöneticileri — teknik metrikleri iş sonuçlarıyla ilişkilendirip karar almak için.

Hangi problemleri çözüyor?

• Pipeline, uygulama ve altyapı objektif performans gözlemi sağlar.
• SLO odaklı uyarı ile yanlış alarm yükünü azaltır ve operasyonel aksiyonları netleştirir.
• Kapasite planlaması ve maliyet optimizasyonu için güvenilir veri sunar.

2. KAVRAMSAL TEMELLER

2.1 Metrik türleri

• Counter: Sürekli artan sayaçlar (ör. istek sayısı, hata sayısı). Reset durumları ele alınmalı.
• Gauge: Her anki değeri gösteren ölçümler (örn. CPU kullanım oranı, queue length).
• Histogram/ Summary: Latency dağılımları ve percentil hesapları için kullanılır (p95, p99).
• Derived metrics: Rate, ratio veya farklı metriklerden türetilen göstergeler (ör. success rate).

2.2 Time series paradigması

Metricler zaman serisi (time series) olarak tutulur: her veri noktası bir timestamp, isim ve etiketler (labels) içerir. Time series veri modellerinde verinin cardinality (etiket kombinasyonlarının sayısı) ve retention stratejileri maliyet ve performans üzerinde doğrudan etkilidir.

2.3 Terminoloji

• Scrape vs Push: Prometheus tarzı pull (scrape) modeli veya push gateway/agent ile push modeli.
• Cardinality: Label kombinasyonlarının sayısı — yüksek cardinality maliyeti ve sorgu gecikmesini artırır.

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

3.1 Yüksek seviyeli mimari

Tipik bir metrics sisteminin bileşenleri: instrumentasyon (SDK), exporter/agent (OTel Collector, Prometheus exporter), ingestion (scrape veya push gateway), zaman serisi store (Prometheus TSDB, Cortex, Thanos, VictoriaMetrics), query layer (PromQL/Flux), alerting (Alertmanager) ve görselleştirme (Grafana). Ayrıca long‑term storage ve downsampling katmanları da bulunur.

3.2 Instrumentasyon — OpenTelemetry ve Prometheus client'ları

Uygulama seviyesinde doğru enstrümantasyon kilit önemdedir. OpenTelemetry SDK'ları metrics, traces ve logs'ı entegre bir şekilde sağlar. Prometheus client kütüphaneleri de lightweight ve doğrudan metric exposition için yaygındır. Enstrümantasyonun iyi olması için semantic naming (öznitelik adlandırma), metrik tipine uygun veri gönderme ve label kullanımında tutarlılık gereklidir.

3.3 Scrape modeli ve pull‑based collection

Prometheus gibi sistemlerde collector (Prometheus server) hedefleri düzenli aralıklarla (scrape interval) sorgular. Bu model, güvenilir keşif (service discovery) ve firewall friendly iletişim avantajları sağlar. Ancak kısa süreli job'lar veya ephemeral instance'lar için push modeli veya push gateway gerekebilir.

3.4 Ingestion, retention ve downsampling

Ingest edilen metrikler yüksek hacimli olabilir. Retention planı (kısa dönem yüksek granularity, uzun dönem düşük granularity) ve downsampling stratejileri hem maliyet hem de sorgu performansı için gereklidir. Thanos veya Cortex gibi çözümler long‑term retention ve global query için uygundur; VictoriaMetrics yüksek ingest performansı ve depolama verimliliği ile bilinir.

3.5 Cardinality kontrolü

Etiket (label) kullanımında dikkat edilmesi gereken en önemli noktalardan biri cardinality'dir. Örneğin user_id gibi yüksek cardinality değerleri doğrudan metric label'ı olarak kullanmak çok sayıda time series yaratır. Bunun yerine user‑level detaylar traces/logs içinde, metrics'te ise aggregate veya bucket'lar şeklinde tutulmalıdır.

3.6 Query ve hesaplama — PromQL

PromQL gibi zaman serisi sorgu dilleri, rate ve histogram işlemleri, alerting rule'ları ve SLO hesapları için güçlü araçlardır. Ancak karmaşık PromQL sorguları sorgu maliyetini artırabilir; query cache ve query federasyon stratejileri ile performans iyileştirilir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix, Uber ve large scale metric rollouts

Büyük ölçekli şirketler metrik mimarilerini kendi ihtiyaçlarına göre optimize etmiştir. Netflix, metrics'i operasyonel ve iş kararlarına entegre eder; Uber, yüksek cardinality ve event‑driven metrikleri yönetmek için özel çözümler geliştirir. Bu tür organizasyonlarda prometheus bileşenleri üzerinde ölçeklendirme, federasyon ve özel storage çözümleri uygulanır.

4.2 Fintech ve SLO odaklı operasyon

Finansal servisler için latency, success rate ve ödeme işlemleri gibi metrikler iş açısından kritik SLO'lar haline gelir. Metrik sistemi aynı zamanda compliance raporlaması ve SLA takibi için veri kaynağıdır.

4.3 Startuplar — maliyet/öncelik dengesi

Startuplar genelde Prometheus + Grafana + managed storage kombinasyonlarıyla başlar. Maliyeti düşük ve hızlı kurulum sağlarken, zamanla metriğin ölçeklenmesi için Thanos veya Cortex gibi çözümlere geçiş yaparlar.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Gerçek zamanlı sistem sağlığı ve trend analizi sağlar.
• SLO/SLI bazlı operasyon ile iş hedefleriyle teknik hedefleri ilişkilendirir.
• Doğru enstrümantasyon ile root cause analysis hızlanır.

Sınırlamalar

• High cardinality ve yüksek ingest maliyetleri yönetim zorluğu getirir.
• Retention ve sorgu maliyetleri finansal baskı oluşturabilir.
• Yanlış adlandırma ve label sapmaları veri kalitesini bozar; governance gerekir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Öncelikle 1–3 kritik SLO belirleyin; metrik ve alert tasarımlarınızı SLO'ya göre yapın.
• Metrik adlandırma standardı ve label politikasını dokümante edip enforce edin.
• Cardinality limitleri koyun; kullanıcı‑bazlı ID'leri metrics'te değil traces/logs'ta tutun.

Performans optimizasyonu

• Scrape interval ve retention stratejilerini iş ihtiyaçlarına göre dengeleyin (short vs long term).
• Downsampling ve rollup ile eski verilerin granülerliğini azaltın.
• Query cache ve federation ile sorgu yükünü optimize edin.

Güvenlik

• Metrics pipeline'ında PII içeren label ve değerleri filtreleyin; collector seviyesinde redaction uygulayın.
• Telemetry backends erişimini RBAC ile sınırlandırın ve audit loglarını saklayın.

Ölçeklenebilirlik

• Ingestion katmanını autoscaling ve backpressure mantığı ile tasarlayın.
• Federated Prometheus veya sharding stratejileri ile veri parçalamayı uygulayın.

8. SIK YAPILAN HATALAR

• Metriklerin düzensiz adlandırılması ve label sapmaları — veri tutarsızlığı yaratır.
• High cardinality etiketlerin kontrolsüz eklenmesi — performans ve maliyet patlaması.
• Alert'leri ham eşik değerlerine göre koymak — false positive/negative artışı.
• Retention ve cold storage planı olmadan veri biriktirmek — maliyet yönetiminde başarısızlık.

9. GELECEK TRENDLER

1. Observability as Data: Metrik verisinin ML modellerine entegre edilmesi ile anomaly detection ve kapasitasyon önerileri yaygınlaşacak.
2. Edge ve IoT metrikleri: Merkezi toplama yerine hibrit ve lokal preprocessing modelleri artacak.
3. Unified observability: Metrics, traces ve logs tek bir data plane ve sorgu diliyle daha sık entegre edilecek.
4. Cost‑aware telemetry: Metrik toplama ve retention politikaları maliyet odaklı otomatikleştirilecek (auto‑downsample, archive triggers).

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Prometheus mu yoksa managed çözüm mü tercih etmeliyim?

   Başlangıç için Prometheus + Grafana yeterlidir ve maliyet etkindir; ancak ölçek, SLA ve operasyonel kaynak kısıtları varsa managed çözümler (Grafana Cloud, Datadog) değerlendirilmeli.

2. 2. Cardinality nasıl ölçülür ve kontrol edilir?

   Öncelikle hangi label'ların yüksek cardinality ürettiğini izleyin. User‑id veya request_id gibi dinamik değerleri metrics'e sokmayın; alternatif olarak hash/partition veya rollup kullanın.

3. 3. Metrics retention politikası nasıl olmalı?

   Hızlı araştırma için recent high‑granularity (ör. 15–30 gün), uzun dönem trend ve raporlama için low‑granularity (ör. 90–365 gün) şeklinde katmanlandırma uygulayın.

4. 4. Histogram ile summary arasındaki fark nedir?

   Histogram bucket bazlıdır ve bucket'lar üzerinden percentil hesaplamalarına izin verir; summary ise client‑side percentil hesapları yapar. Genelde server side histogram daha esnektir.

5. 5. SLO'ları metrics ile nasıl bağlarım?

   SLO için uygun SLI (ör. success rate, latency p95) seçin. Prometheus rule'ları ile error budget hesaplayın ve Alertmanager veya otomatik mitigasyonlarla error budget tüketimine göre aksiyon alın.

6. 6. Metrik koleksiyonunda OpenTelemetry nasıl kullanılır?

   OpenTelemetry SDK'larıyla uygulamayı instrument edip collector üzerinden Prometheus veya başka backend'e export edebilirsiniz. OTel, metric, trace ve log'ları birleştirerek unified telemetry sağlar.

7. 7. Metriklerin doğruluğunu nasıl garanti edersiniz?

   Instrumentasyon testleri, metrics unit test'leri, synthetic load test'leri ve end‑to‑end scrape doğrulamaları ile veri kalitesini sürekli test edin.

8. 8. Metrik pipeline'ında güvenlik için ne yapmalıyım?

   Telemetry verisini encrypt edin, collector erişimlerini RBAC ile sınırlandırın ve PII içeren label/values için redaction uygulayın.

Anahtar Kavramlar

Time Series

Zaman damgasına bağlı olarak toplanan veri noktaları; metriklerin temel veri modeli.

Cardinality

Label kombinasyonlarının sayısı; kontrol edilmezse performans sorunları yaratır.

Downsampling

Eski verilerin granülerliğini azaltma işlemi—retention maliyetini düşürür.

SLO / SLI

Service Level Objective ve Service Level Indicator—kullanıcı odaklı performans hedefleri ve göstergeleri.

PromQL

Prometheus sorgu dili—zaman serisi verileri üzerinde hesaplama ve alarmlar kurmak için kullanılır.

Öğrenme Yol Haritası

1. 0–1 ay: Metrics temel kavramları, Prometheus client kütüphaneleri ve Grafana dashboard temel bilgileri öğrenin.
2. 1–3 ay: OpenTelemetry entegrasyonu, Prometheus scrape modeli, temel PromQL sorguları ve alert rule'ları üzerinde pratik yapın.
3. 3–6 ay: Thanos/Cortex/VictoriaMetrics gibi long‑term storage çözümlerini deneyin; downsampling ve retention stratejileri oluşturun.
4. 6–12 ay: SLO/SLI lifecycle, error budget yönetimi, cardinality kontrolü, cost‑aware telemetry ve ML‑assisted anomaly detection konularında deneyim kazanın.