1. GİRİŞ

Prometheus, modern bulut‑native ortamların metrik toplama ve uyarı ihtiyaçları için en yaygın kullanılan açık kaynak zaman serisi izleme sistemlerinden biridir. Kubernetes ve microservice ekosisteminin yükselişiyle birlikte Prometheus'un pull‑based yaklaşımı, PromQL sorgu dili ve geniş exporter ekosistemi operasyonda ve geliştiriciler arasında kabul görmüştür. Ancak yüksek hacimli, global dağıtık sistemlerde Prometheus'un temel mimarisi doğrudan yeterli olmayabilir; bu nedenle Thanos, Cortex veya managed çözümler gibi ölçeklendirici katmanlar devreye girer.

Neden bugün önemli?

• Kubernetes ve mikroservis mimarileri, çok sayıda kısa ömürlü hedef üretir — Prometheus bu tür yapılarla doğal bir uyum gösterir.
• SLO/SLI odaklı operasyon pratikleri metriklere dayalı karar alma modellerini zorunlu kılıyor; Prometheus güçlü bir SLI platformu sağlar.
• OpenTelemetry ve exporter'ların yaygınlaşması ile Prometheus ekosistemi genişliyor; doğru mimari tasarım kritik hale geldi.

Kimler için önemli?

• SRE ve platform ekipleri — sistem sağlığını ve kapasitasyonu yönetmek için.
• Geliştiriciler — uygulama performansını ölçüp optimize etmek için.
• CTO/teknoloji liderleri — operasyonel metrikleri iş hedefleriyle bağlamak için.

Hangi problemleri çözüyor?

• Gerçek zamanlı metriği (time series) toplayıp sorgulama ve görselleştirme imkânı sunar.
• SLO/alerting ile operasyonel olgunluğu artırır.
• Prometheus exporter/SDK ekosistemiyle heterojen sistemler için tek bir metrik modeli sunar.

2. KAVRAMSAL TEMELLER

2.1 Temel kavramlar ve terminoloji

• Metric (metrik): Bir isim, zaman damgası ve label (etiket) kümesi ile temsil edilen sayısal ölçüm (counter, gauge, histogram, summary).
• Scrape: Prometheus'un hedefleri periyodik olarak sorgulama modeli; hedefler /metrics endpoint'i sunar.
• TSDB (Time Series Database): Prometheus'un yerel storage'ı; veriyi .wal ve block'lar halinde tutar.
• PromQL: Prometheus sorgu dili; alert, dashboard ve SLO hesapları için temel.
• Alertmanager: Prometheus alert'lerini yöneten, gruplayan ve bildirim kanallarına (email, Slack, PagerDuty) ileten bileşen.

2.2 Metrik tipleri

• Counter: Artan sayılar (ör. istek sayısı). Reset durumlarını PromQL ile ele almak gerekir.
• Gauge: Anlık değerler (örn. bellek kullanımı, kuyruk uzunluğu).
• Histogram: Latency dağılımı için bucket'lar; p95/p99 hesaplaması için kullanışlı.
• Summary: Client‑side percentil hesapları; deploy senaryolarında dikkatli kullanmak gerekir.

2.3 Pull (scrape) vs push modeli

Prometheus, pull‑based bir model kullanır: Prometheus server hedeflerin /metrics endpoint'ini periyodik olarak çeker. Pull avantajları arasında servis keşfi, firewall‑friendly iletişim ve eksik verinin kolay tespiti sayılabilir. Kısa ömürlü batch job'lar veya push gerektiren senaryolar için Pushgateway veya agent‑based push pattern'leri kullanılır. Ancak push gateway kullanımında metric lifecycle kontrolü dikkatli tasarlanmalıdır.

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

3.1 Prometheus bileşenleri

1. Prometheus server: Scrape scheduler, TSDB, PromQL engine ve rule evaluator içerir.
2. Exporter'lar: Node Exporter, cAdvisor, application exporters ve custom client libraries (/metrics endpoint üretir).
3. Service Discovery: Kubernetes, Consul, EC2, DNS gibi mekanizmalarla hedef keşfi yapılır.
4. Alertmanager: Alert routing, inhibition, silencing ve notification handling sağlar.
5. Visualization & dashboard: Grafana en yaygın kullanılan araçtır; Prometheus datasource ile doğrudan query yapılır.

3.2 TSDB ve veri blokları

Prometheus TSDB (local storage) veri bloklarını 2 saatlik segmentler halinde yazar. Her blok içinde zaman serileri sıkıştırılmış biçimde tutulur; ayrıca WAL (write‑ahead log) ile güvenli yazma sağlanır. Disk tabanlı TSDB performansı, I/O kapasitesi, disk throughput ve block retention ayarlarına bağlıdır.

3.3 Scrape scheduler ve hedef keşfi

Prometheus, her job için scrape interval ve timeout tanımlar. Service discovery adaptörleri dinamik ortamlarda hedefleri güncellemek için kullanılır (örn. Kubernetes Endpoints, pod annotations). Scrape timeout değerleri network gecikmeleri ve yüksek GC zamanlarına karşı dikkatlice optimize edilmelidir.

3.4 PromQL ve rule evaluation

PromQL, metric transformasyonları, aggregation ve alert rule'ları için kullanılır. Rule evaluator, belirli periyotlarda kayıtlı rule'ları çalıştırıp sonuçlarını TSDB'ye yazar ve alertmanager'a kurallara göre alert gönderir. Karmaşık PromQL sorguları CPU/ram maliyetini artırabilir; rule'ları optimize etmek ve recording rule (önceden hesaplanan seri) kullanmak iyi pratiktir.

3.5 Alertmanager ve alert lifecycles

Alertmanager alert'leri alır, benzer alert'leri gruplayıp inhibit ve routing kurallarına göre farklı receiver'lara yönlendirir. Oncall süreçleri için doğru grup ve severity yapılandırması kritik; örneğin error budget tüketim uyarıları ile operational alert'leri ayırmak operasyonel gürültüyü azaltır.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Kubernetes ortamında Prometheus

Kubernetes'de Prometheus, cluster seviyesinde node, kube‑system ve uygulama metriklerini toplamak için yaygın bir tercihtir. Kube‑state‑metrics, cAdvisor ve kubelet metric'leri ile cluster sağlık göstergeleri oluşturulur. Prometheus operator (kube‑prometheus-stack) ile manifests, ServiceMonitor ve PodMonitor kaynakları kullanılarak yönetim kolaylaşır.

4.2 Netflix, Uber ve büyük ölçek

Netflix ve Uber gibi ölçekli organizasyonlar, Prometheus paradigmasını farklı çözümlerle genişleterek yüksek ingest ve long‑term retention ihtiyaçlarını karşılar — Thanos veya Cortex gibi katmanlar ölçekleme, global query ve uzun dönem saklama sağlar. Ayrıca özel cardinality kontrol stratejileri ile maliyeti yönetirler.

4.3 Managed çözümler ve enterprise kullanımı

Büyük kuruluşlar için Grafana Cloud, Prometheus on managed platforms veya vendor APM çözümleri hızlı başlangıç sağlar. Managed servisler operasyonel yükü azaltırken maliyet ve lock‑in düşünülmelidir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Basit, etkili pull‑based model; servis keşfi ile uyumlu çalışır.
• PromQL ile güçlü sorgu yetenekleri ve recording rule'larla ön hesaplama.
• Zengin exporter ekosistemi ve geniş topluluk desteği.

Sınırlamalar

• Yerel Prometheus tek başına global scale ve long‑term retention için yetersiz olabilir.
• High cardinality label'lar TSDB büyümesini hızlandırır ve maliyeti artırır.
• Operational overhead: Elasticsearch gibi managed olmayan büyük dağıtımlar için işletme yükü artar.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Her cluster için dedicated Prometheus instance'ları kullanın; multi‑tenant ihtiyaçlar için Thanos veya Cortex değerlendirin.
• Recording rule'ları ile ağır sorguları önceden hesaplayın ve dashboard/alert için kullanın.
• Alert'leri SLO/SLI'ya göre tasarlayın; error budget ile otomatik aksiyon entegrasyonu kurun.

Performans optimizasyonu

• Scrape interval'larını hedef önceliğine göre ayarlayın (kritik servisler daha sık, infrequent servisler daha seyrek).
• High cardinality'e yol açan label'ları azaltın; user‑id gibi dinamik değerleri metrics'te tutmayın.
• Retention politikaları ve downsampling stratejileri planlayın; object storage kullanarak maliyeti düşürün.

Güvenlik

• Prometheus scrape endpoint'lerini authentication/authorization ile koruyun (kubernetes ServiceMonitor RBAC, TLS, basic auth/MTLS).
• Telemetry verisini encrypt edin ve storage erişimini RBAC ile sınırlandırın.

Ölçeklenebilirlik

• Shard / federation stratejileri ile veri parçalama yapın; federated Prometheus ile global view sağlayın.
• Thanos/Cortex ile long‑term storage ve global query mimarisini planlayın.

8. SIK YAPILAN HATALAR

• Label politikası olmadan metrics üretmek — cardinality explosion riski.
• Recording rule veya aggregation eksikliği — dashboard'larda pahalı sorgular çalıştırmak.
• Pushgateway'ı yanlış kullanmak — transient job lifecycler'ı ile senkronizasyon sorunları.
• Alert'leri ham eşiklere göre koymak — yanlış tetiklenmeler ve oncall tükenmesi.

9. GELECEK TRENDLER

1. OpenTelemetry entegrasyonu: Prometheus veri modelinin OpenTelemetry ile daha yakın entegrasyonu, unified telemetry akışları sağlayacak.
2. Cost‑aware metric management: Otomatik downsample ve retention trigger'ları ile maliyet optimizasyonu otomatikleşecek.
3. AI‑assisted anomaly detection: Metrik patlamalarını ve anormallikleri ML modelleriyle erken tespit etme yaygınlaşacak.
4. Edge ve hybrid monitoring: Çoklu ortam (edge, on‑prem, cloud) monitoring için hafif agent ve local aggregation çözümleri artacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Prometheus'u Kubernetes'te nasıl ölçeklendiririm?

   Her node/cluster için dedicated Prometheus kullanın, ServiceMonitor ve PodMonitor ile hedef keşfini yönetin. Global query ve long‑term retention için Thanos veya Cortex ekleyin.

2. 2. Thanos mu yoksa Cortex mi seçmeliyim?

   Thanos daha çok mevcut Prometheus yatırımlarını object storage ile uzatmak ve global query sağlamak için uygundur. Cortex ise multi‑tenant, yüksek performanslı, dağıtık TSDB sunar. Seçim ihtiyaçlara, multi‑tenant gereksinimine ve operasyon ekibinin yetkinliğine bağlıdır.

3. 3. PromQL sorguları neden yavaş çalışıyor?

   Çok geniş zaman aralıkları, yüksek cardinality ve kompleks aggregasyonlar sorgu süresini uzatır. Recording rule kullanarak önceden hesaplama yapın ve grafana dashboard'larında bu recording metric'leri kullanın.

4. 4. High cardinality sorununu nasıl tespit ederim?

   Prometheus'in TSDB bloklarını ve seri sayısını izleyin; ayrıca label cardinality raporları çıkarın. Hangi label'ların en fazla seri yarattığını tespit edip azaltın.

5. 5. Pushgateway ne zaman kullanılmalı?

   Pushgateway, kısa ömürlü batch job'ların metriklerini Prometheus'a iletmek için kullanılır. Ancak pushgateway metric lifecycle'ını iyi yönetmeli, job completion sonrası push edilen metric'in temizlenmesini sağlamalısınız.

6. 6. Prometheus verisini nasıl uzun süre saklarım?

   Prometheus local retention'ı kısa tutup, Thanos sidecar + object storage (S3, GCS) kullanarak veri bloklarını uzun süre saklayabilirsiniz. Cortex veya VictoriaMetrics da alternatif long‑term çözümler sunar.

7. 7. Prometheus güvenliği için ne yapmalıyım?

   Scrape endpoint'lerini TLS ve authentication ile koruyun; ServiceMonitor RBAC, network policies ve firewall kuralları uygulayın. Ayrıca storage erişimini ve snapshot'ları güvenli yerde saklayın.

8. 8. Prometheus yerine managed bir çözüm almak mantıklı mı?

   Operasyonel kaynaklar sınırlıysa managed çözümler (Grafana Cloud, AWS Managed Prometheus) operasyonel yükü azaltır. Ancak maliyet ve vendor lock‑in faktörlerini değerlendirmeniz gerekir.

Anahtar Kavramlar

Prometheus

Pull‑based metrik toplama, TSDB ve PromQL sunan açık kaynak monitoring sistemi.

TSDB

Zaman serisi veritabanı — Prometheus'un local storage katmanı.

Thanos

Prometheus'u object storage ile entegre ederek long‑term retention ve global query sağlayan katman.

Cortex

Prometheus uyumlu, dağıtık, multi‑tenant TSDB çözümü.

PromQL

Prometheus sorgu dili — aggregation, rate ve alert tanımları için kullanılır.

Öğrenme Yol Haritası

1. 0–1 ay: Prometheus temel kavramları, PromQL basit sorguları ve Grafana ile dashboard oluşturmayı öğrenin.
2. 1–3 ay: Kubernetes'te Prometheus operator, ServiceMonitor ve exporter'lar ile gerçek dünya uygulaması kurun.
3. 3–6 ay: Thanos veya Cortex ile long‑term retention, shard/federation stratejileri ve recording rule'lar üzerinde çalışın.
4. 6–12 ay: Large scale monitoring, cardinality kontrolü, cost‑aware telemetry ve SLO lifecycle yönetimi konularında deneyim kazanın.