Cloud & DevOpsAltyapı & İzleme

Prometheus Nedir? Zaman Serisi İzleme ve Metrik Platformu

••21 dk okuma•Güncellendi: 08.05.2026
Prometheus Nedir? Zaman Serisi İzleme ve Metrik Platformu

Temel Kavramlar: Metrik, Scrape ve Zaman Serisi

Prometheus, 2012 yılında SoundCloud'da doğmuş ve 2016'da Cloud Native Computing Foundation'a katılmış açık kaynaklı bir izleme ve uyarı sistemidir. Zaman serisi veritabanı (TSDB) tabanlı mimarisi, pull modeli ile metrik toplama yaklaşımı ve güçlü sorgu dili PromQL ile modern altyapı izleme ihtiyaçlarına cevap verir. Özellikle Kubernetes ekosisteminin vazgeçilmez bir parçası haline gelmiştir.

Sistem, metrikleri HTTP endpoint'lerinden düzenli aralıklarla "scrape" ederek toplar. Her metrik, zaman damgası ve etiket çiftleriyle birlikte saklanır. Bu yapı, dinamik ve ölçeklenebilir ortamlarda servis keşfini ve izlemeyi kolaylaştırır. Cross-platform çalışabilirliği sayesinde Linux, Windows ve container ortamlarında sorunsuz deploy edilebilir. Profesyonel ekiplerde, altyapı sağlığını anlık takip etmek ve sorunları proaktif olarak tespit etmek için ilk tercih edilen araçlardan biridir.

Metrik Türleri Nedir ve Nasıl Kullanılır?

Prometheus dört temel metrik tipi tanımlar: Counter, Gauge, Histogram ve Summary. Counter, yalnızca artan değerleri temsil eder (örneğin toplam istek sayısı). Gauge, artıp azalabilen anlık değerler içindir (CPU kullanımı, bellek miktarı). Histogram, gözlemleri kovalara (bucket) ayırarak dağılımı ölçer (istek süreleri). Summary ise, hesaplanan yüzdelik dilimler (quantile) sunar.

Metrik seçimi, toplanan verinin doğru şekilde yorumlanması için kritiktir. Yanlış tip seçimi, yanlış alarm kuralları veya yanıltıcı dashboard'lar oluşturabilir. Örneğin, bir API'nin toplam istek sayısını Counter ile takip ederken, anlık aktif bağlantı sayısını Gauge ile ölçmelisiniz. Histogram'lar, SLA takibi ve performans optimizasyonu çalışmalarında paha biçilmez veriler sunar.

# Histogram metrik örneği
http_request_duration_seconds_bucket{
  le="0.1", 
  method="GET", 
  endpoint="/api/users"
} 240

http_request_duration_seconds_bucket{
  le="0.5", 
  method="GET", 
  endpoint="/api/users"
} 900

Scrape Konfigürasyonu Nasıl Yapılandırılır?

Prometheus, prometheus.yml dosyası üzerinden hangi hedeflerden (target) ne sıklıkla metrik toplayacağını belirler. scrape_configs bölümünde, her bir job için farklı endpoint'ler, interval süreleri ve timeout değerleri tanımlanabilir. Statik hedeflerin yanı sıra, DNS, Consul, Kubernetes gibi servis keşif mekanizmaları da desteklenir.

scrape_interval (varsayılan 1m) ve scrape_timeout (varsayılan 10s) değerleri, hem veri doğruluğu hem de sistem yükü açısından dikkatle ayarlanmalıdır. Çok sık scrape yapmak ağ ve hedef sistem üzerinde yük oluştururken, çok seyrek yapmak anlık sorunları kaçırmanıza neden olabilir. TLS, basic auth ve bearer token gibi güvenlik yapılandırmaları da bu dosya üzerinden yönetilir.

# prometheus.yml scrape konfigürasyonu
scrape_configs:
  - job_name: 'api-services'
    scrape_interval: 15s
    static_configs:
      - targets: ['api-1:8080', 'api-2:8080']
    metrics_path: '/actuator/prometheus'

Zaman Serisi Veri Modeli ve Etiketleme Örnekleri

Prometheus'ta her veri noktası bir zaman serisidir ve benzersiz etiket kombinasyonuyla tanımlanır. Metrik adı ve etiket çiftleri (label set), serinin kimliğini oluşturur. Örneğin http_requests_total{method="GET",status="200",endpoint="/api"} farklı bir seridir than http_requests_total{method="POST",status="200",endpoint="/api"}.

Etiketleme stratejisi, sorgulama esnekliği ve depolama maliyeti arasında denge kurmalıdır. Çok fazla yüksek kardinaliteli etiket (örneğin user_id veya request_id), zaman serisi sayısını patlatır ve hem bellek hem de disk kullanımını şişirir. En iyi pratik, servis adı, ortam (prod/staging), instance ve endpoint gibi düşük kardinaliteli etiketleri kullanmaktır. Bu, test edilebilirlik ve debugging süreçlerinde de faydalıdır.

# İyi etiketleme örneği
api_request_duration_seconds{
  service="payment-service",
  environment="production",
  method="POST",
  endpoint="/v1/charge",
  status="200"
}

Görselleştirme ve Dashboard Entegrasyonu

Ham metrik verisi, anlamlı bilgiye dönüşmediği sürece izleme stratejisinin bir parçası olamaz. Prometheus'un kendi expression browser'ı basit sorgular için yeterli olsa da, üretim ortamlarında kapsamlı dashboard'lar ve görselleştirme araçları şarttır. Grafana, bu noktada ekosistemin en popüler tamamlayıcısıdır. PromQL sorgularını zengin görsel widget'lara dönüştürerek, ekiplerin sistem durumunu tek bakışta anlamasını sağlar.

UI/UX odaklı izleme, sadece teknik ekipleri değil, ürün yöneticileri ve iş birimlerini de hedefler. Kullanıcı deneyimi metrikleri (sayfa yükleme süreleri, API latency, hata oranları), doğrudan müşteri memnuniyeti ile ilişkilidir. Responsive tasarım prensipleri, dashboard'ların mobil cihazlardan da okunabilir olmasını gerektirir. Özellikle on-call ekipler için, telefon ekranından bile kritik alarmları görebilmek hayati öneme sahiptir.

Grafana ile Dashboard Nasıl Oluşturulur?

Grafana, Prometheus'u data source olarak ekledikten sonra PromQL sorguları ile paneller oluşturmanıza olanak tanır. Her panel, bir veya birden fazla sorgu içerebilir ve farklı görselleştirme tipleri (graph, singlestat, table, heatmap, gauge) kullanabilir. Templating özelliği sayesinde, ortam, servis veya instance gibi değişkenler tanımlanarak dinamik dashboard'lar oluşturulur.

Dashboard tasarlarken, bilgi hiyerarşisine dikkat etmek gerekir. En kritik metrikler (SLO'lar, hata oranları) üst sıralarda ve büyük panellerde yer almalıdır. Drill-down imkanı sunarak, özetten detaya inmeyi mümkün kılmak, debugging sürecini hızlandırır. Alerting kuralları ile dashboard'ları birleştirmek, görsel izleme ve proaktif uyarı mekanizmalarını tek çatı altında toplar.

# Grafana panel sorgu örneği
sum(rate(http_requests_total{status=~"5.."}[5m])) 
/ 
sum(rate(http_requests_total[5m]))

UI/UX Odaklı Metrik Görselleştirme Örnekleri

Kullanıcı deneyimini doğrudan etkileyen metrikler, farklı bir görselleştirme yaklaşımı gerektirir. Apdex skoru, kullanıcı memnuniyetini 0-1 arası tek bir değerde özetler. Heatmap'ler, istek sürelerinin dağılımını zaman ekseninde göstererek performans optimizasyonu noktalarını ortaya çıkarır. Geo-map panelleri, mobil uygulama kullanıcılarının coğrafi dağılımını ve bölgesel latency'leri görselleştirir.

Renk kodlaması ve threshold'lar, dashboard'ların anlaşılırlığını artırır. Kritik değerler kırmızı, uyarılar sarı, normal durumlar yeşil ile belirtilmelidir. Ancak renk körü kullanıcıları düşünerek, yalnızca renge değil sembollere ve metin değerlerine de yer vermek gerekir. E-ticaret sitelerinde, conversion funnel'ını izleyen dashboard'lar, teknik metrikleri iş metrikleriyle birleştirerek daha kapsamlı bir görünüm sunar.

# Apdex skoru hesaplama
(
  sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) +
  sum(rate(http_request_duration_seconds_bucket{le="1.2"}[5m]))
) / 2 / sum(rate(http_request_duration_seconds_count[5m]))

Responsive Tasarımda Metrik Panelleri Nasıl Optimize Edilir?

Modern izleme anlayışı, dashboard'ların sadece büyük monitörlerde değil, tüm cihazlarda erişilebilir olmasını gerektirir. Grafana'nın responsive grid sistemi, panellerin ekran boyutuna göre yeniden düzenlenmesini sağlar. Ancak, mobil cihazlarda her metriğin gösterilmesi kullanıcı deneyimini bozabilir. Önem sırasına göre panel düzeni yapmak ve mobil görünümde detayları gizlemek (collapse) daha akıllıcadır.

Panel başlıkları ve açıklamaları kısa ve öz tutulmalıdır. Uzun PromQL sorguları, panelin altındaki açıklama alanına taşınabilir. Threshold değerleri, mobil ekranda bile net görünecek şekilde ayarlanmalıdır. Cross-platform erişim, on-call rotasyonlarında farklı cihazlardan sisteme müdahale edebilme esnekliği sunar. Özellikle agile ekiplerde, hızlı karar almayı destekleyen sade ve etkili dashboard'lar tercih edilir.

# Mobil-uyumlu sorgu (basitleştirilmiş)
up{job="critical-services"}

Yerleşim ve Mimari Düzenlemeler

Prometheus kurulumu, projenin büyüklüğüne ve kritikliğine göre farklı mimariler gerektirir. Tek node kurulumu, geliştirme ortamları ve küçük üretim sistemleri için yeterlidir. Ancak yüksek erişilebilirlik (HA) gerektiren kurumsal projelerde, birden fazla Prometheus instance'ı ve uzun vadeli depolama çözümleri (Thanos, Cortex, VictoriaMetrics) devreye girer. Mimari karar, erken aşamada verilmeli ve gelecekteki büyümeye uygun şekilde planlanmalıdır.

Pull modeli, Prometheus'un temel felsefesidir. Hedef sistemlerin metrik endpoint'i açması yeterlidir; Prometheus bunları periyodik olarak çeker. Ancak kısa ömürlü batch job'lar veya firewall arkasındaki sistemler için Pushgateway kullanılabilir. Kubernetes ortamında, servis keşfi otomatiktir; pod'lar dinamik olarak eklendiğinde veya çıkarıldığında Prometheus hedef listesini otomatik günceller. Bu, container orchestrasyon dünyasında operasyonel yükü önemli ölçüde azaltır.

Tek Node vs HA Kurulumu Nasıl Yapılır?

Tek node kurulumu, binary dosyayı indirip çalıştırmak kadar basittir. Veri local diskte saklanır ve yapılandırma tek bir YAML dosyasından yönetilir. Ancak bu kurulumda, node çökerse hem izleme hem de veri kaybı yaşanır. HA kurulumunda ise, birden fazla Prometheus instance'ı aynı hedefleri scrape eder ve veriyi replike eder. External storage (object storage) ile uzun vadeli saklama sağlanır.

Federated setup, merkezi bir Prometheus'un farklı datacenter'lardaki Prometheus'ları sorgulamasına olanak tanır. Bu, global görünürlük sağlarken, local instance'ların bağımsız çalışmasını korur. Veri kaybı riskini minimize etmek için, remote_write ile veriyi eşzamanlı olarak uzun vadeli depolamaya göndermek en iyi pratiktir. Profesyonel ekiplerde, production ortamlarında mutlaka HA yapılandırması tercih edilir.

# HA için external label
global:
  external_labels:
    replica: 'prometheus-1'

# Remote write konfigürasyonu
remote_write:
  - url: "http://thanos-receive:19291/api/v1/receive"

Pushgateway ve Pull Modeli Örnekleri

Pull modeli, hedef sistemlerin sağlıklı olup olmadığını doğal olarak kontrol eder. Eğer bir endpoint'e ulaşılamıyorsa, metrik eksikliği bir alarm tetikleyebilir. Ancak batch job'lar, CI/CD pipeline'ları veya serverless fonksiyonlar gibi kısa ömürlü süreçler, Prometheus'un scrape aralığından daha hızlı sonlanabilir. İşte bu noktada Pushgateway devreye girer; metrikler geçici olarak Pushgateway'e gönderilir ve Prometheus oradan çeker.

Pushgateway kullanımında dikkat edilmesi gereken önemli bir nokta, metriklerin sonsuza dek orada kalmamasıdır. Job tamamlandığında metriklerin silinmesi gerekir; aksi halde "son başarılı çalışma" metriği sürekli olarak eski değeri gösterir. Ayrıca, Pushgateway'e çok fazla benzersiz etiket göndermek, kardinalite patlamasına neden olabilir.

# Pushgateway'e metrik gönderme
echo "batch_job_duration_seconds 45.2" | curl \
  --data-binary @- \
  http://pushgateway:9091/metrics/job/backup/instance/db-server-1

Kubernetes Üzerinde İzleme Nasıl Çalışır?

Kubernetes, Prometheus ile neredeyse doğal bir uyum içindedir. Pod'lar, Service'ler ve Endpoint'ler otomatik olarak keşfedilir. kubernetes_sd_configs ile API sunucusuna bağlanarak, cluster içindeki tüm hedefler dinamik olarak izlenir. Her pod'un IP'si ve metadata'sı (namespace, label'lar) otomatik olarak etiket olarak eklenir.

Prometheus, genellikle cluster içinde ayrı bir namespace'de (örneğin monitoring) çalıştırılır. RBAC kuralları ile API sunucusuna erişim yetkisi verilir. ServiceMonitor ve PodMonitor CRD'leri (Custom Resource Definitions), hangi servislerin izleneceğini deklaratif olarak tanımlar. Bu yapı, yeni servis eklendiğinde manuel yapılandırma değişikliği yapmadan otomatik izlemeyi başlatır.

# ServiceMonitor örneği
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: api-metrics
spec:
  selector:
    matchLabels:
      app: payment-api
  endpoints:
  - port: metrics
    interval: 15s

Operator Tabanlı Kurulum Teknik Detayları

Prometheus Operator, Kubernetes üzerinde Prometheus ve ilgili bileşenlerin yönetimini otomatize eder. CRD'ler sayesinde, Prometheus instance'ları, Alertmanager konfigürasyonları ve kuralları Kubernetes manifest'leri gibi tanımlanır. Operator, bu kaynakları izler ve istenen durumu sağlamak için gerekli Pod'ları, ConfigMap'leri ve Service'leri oluşturur.

Helm chart'ları veya ArgoCD gibi GitOps araçları ile Operator kurulumu, tekrarlanabilir ve versiyonlanabilir hale gelir. Alertmanager konfigürasyonu, bir Secret olarak saklanır ve Slack, PagerDuty, OpsGenie gibi kanallara yönlendirme yapılabilir. Operator, Prometheus'un yaşam döngüsünü yönetirken, storage class'lar ve persistent volume claim'ler ile veri kalıcılığını da sağlar.

# Prometheus CRD örneği
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: main
spec:
  serviceMonitorSelector:
    matchLabels:
      team: platform
  resources:
    requests:
      memory: 2Gi
  retention: 30d

Gelişmiş Kullanım: Sorgular ve Kayıt Kuralları

Prometheus'un gücü, topladığı veriyi anlamlı bilgiye dönüştürme yeteneğinde yatar. PromQL, zaman serisi verileri üzerinde aggregation, filtering, matematiksel operasyonlar ve fonksiyonlar uygulamanıza olanak tanır. Ancak karmaşık sorgular her zaman hızlı çalışmayabilir. Recording rules, sık kullanılan veya hesaplaması ağır sorguları önceden hesaplayarak sorgu performansını artırır.

Alerting rules, belirli koşullar sağlandığında Alertmanager'a bildirim gönderir. Kuralların doğru tasarlanması, alarm yorgunluğunu (alert fatigue) önlemek için kritiktir. Her alarmın aksiyon alınabilir olması, önem derecesinin doğru belirlenmesi ve gürültü alarm sayısının minimize edilmesi gerekir. İyi tasarlanmış kurallar, on-call ekiplerin verimliliğini artırır ve olası kesintileri önler.

PromQL Sorgu Dili Nedir ve Nasıl Yazılır?

PromQL, Prometheus'un özel sorgu dilidir ve zaman serisi seçimi, filtering, aggregation ve matematiksel operasyonlar sunar. Temel bir sorgu http_requests_total gibi bir metrik adıdır. Etiketler ile filtreleme yapılabilir: http_requests_total{method="GET",status="200"}. Rate fonksiyonu, counter metriklerin anlık değişim hızını hesaplar: rate(http_requests_total[5m]).

Aggregation operatörleri (sum, avg, max, min, count) etiketlere göre gruplama yapar. sum by (method) (rate(http_requests_total[5m])) sorgusu, her HTTP metodu için dakikadaki istek sayısını verir. Offset modifier, geçmiş veriyi sorgulamayı mümkün kılar ve trend analizi yapmayı kolaylaştırır. Subquery'ler, karmaşık hesaplamaları tek bir ifadede birleştirir.

# Hata oranı sorgusu
sum(rate(http_requests_total{status=~"5.."}[5m])) 
/ 
sum(rate(http_requests_total[5m])) * 100

# 95. yüzdelik dilim
histogram_quantile(0.95, 
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
)

Recording Rules ile Veri Ön-İşleme Örnekleri

Recording rules, PromQL sorgularını periyodik olarak çalıştırır ve sonucu yeni bir zaman serisi olarak kaydeder. Bu, dashboard'larda veya alert'lerde kullanılan karmaşık sorguların her seferinde hesaplanmasını önler. Özellikle rate(), histogram_quantile() gibi hesaplaması yoğun fonksiyonlar için faydalıdır. Kurallar, prometheus.yml'de belirtilen rule dosyalarında tanımlanır.

Kural isimlendirmesi, level:metric:operations formatını takip etmelidir. Örneğin job:http_requests:rate5m, job seviyesinde http_requests metriğinin 5 dakikalık rate'ini ifade eder. Bu standart, kuralların anlaşılırlığını artırır ve ekip içinde tutarlılık sağlar. Recording rules, aynı zamanda veri retention süresini yönetmek için de kullanılabilir; özetlenmiş veri daha uzun süre saklanabilir.

# recording_rules.yml
groups:
  - name: api_rules
    interval: 30s
    rules:
      - record: job:http_requests:rate5m
        expr: sum(rate(http_requests_total[5m])) by (job)
      
      - record: job:http_request_duration:p95
        expr: histogram_quantile(0.95, 
                sum(rate(http_request_duration_seconds_bucket[5m])) by (job, le)
              )

Alerting Rules Nasıl Tasarlanır?

Alerting rules, PromQL ifadeleri ve eşik değerleri içerir. Bir ifade true olduğunda (sonuç boş değilse), alarm ateşlenir. for süresi, koşulun ne kadar süre devam etmesi gerektiğini belirtir; bu, geçici spike'ların alarm oluşturmasını önler. Örneğin, hata oranı %5'in üzerinde ve bu durum 5 dakika devam ederse alarm oluştur.

Alarm severity'leri (critical, warning, info) doğru ayarlanmalıdır. Critical alarm'lar, hemen müdahale gerektiren durumları (servis down, veri kaybı riski) ifade eder. Warning'ler, yakın zamanda aksiyon alınması gereken trendleri gösterir. Alertmanager ile routing tree yapılandırarak, farklı severity ve servisler için farklı bildirim kanalları (Slack, e-posta, PagerDuty) kullanılabilir.

# alerting_rules.yml
groups:
  - name: api_alerts
    rules:
      - alert: HighErrorRate
        expr: job:http_requests:rate5m{status=~"5.."} 
               / job:http_requests:rate5m > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Yüksek hata oranı tespit edildi"

Performans Optimizasyonu ve Depolama Stratejileri

Prometheus'un performansı, topladığı metrik hacmi, sorgu karmaşıklığı ve depolama yapılandırması ile doğrudan ilişkilidir. Varsayılan ayarlar birçok senaryo için yeterli olsa da, büyük ölçekli kurulumlarda ince ayar yapmak gerekir. TSDB (Time Series Database), veriyi bloklar halinde organize eder ve compaction işlemi ile verimli saklama sağlar.

Disk I/O, bellek kullanımı ve CPU tüketimi, izlenmesi gereken temel metriklerdir. Çok fazla hedef scrape etmek, çok karmaşık sorgular çalıştırmak veya çok uzun retention süresi belirlemek, kaynak tüketimini artırır. Performans optimizasyonu, hem Prometheus'un kendi ayarlarından hem de sorgu ve etiketleme stratejisinden geçer.

TSDB Yapılandırması ve Retention Ayarları

Prometheus, veriyi local diskte TSDB formatında saklar. Veri, 2 saatlik bloklar halinde yazılır ve daha sonra compaction ile birleştirilir. --storage.tsdb.retention.time flag'i ile varsayılan 15 günlük retention süresi ayarlanabilir. --storage.tsdb.retention.size ile disk kullanımı sınırlandırılabilir; bu limit aşıldığında en eski veri silinir.

Uzun vadeli saklama ihtiyacı olan projelerde, remote_write ile Thanos, Cortex veya VictoriaMetrics gibi external storage çözümlerine veri gönderilir. Bu sayede local disk yükü hafifler ve veri yıllarca saklanabilir. Ancak local query ile remote query arasındaki performans farkı göz önünde bulundurulmalıdır. Profesyonel ekiplerde, operasyonel metrikler 15-30 gün local, iş analitiği metrikleri ise uzun vadeli depoda tutulur.

# Retention ayarları ile çalıştırma
prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.retention.time=30d \
  --storage.tsdb.retention.size=50GB

Veri Sıkıştırma ve Disk Yönetimi Örnekleri

TSDB, veriyi otomatik olarak sıkıştırır. Her blok, compaction sonrası daha az disk alanı kullanır. Ancak yüksek kardinaliteli metrikler (çok fazla benzersiz zaman serisi), sıkıştırma oranını düşürür ve disk kullanımını artırır. prometheus_tsdb_head_series metriği, aktif zaman serisi sayısını gösterir ve bu değerin trendi izlenmelidir.

Disk yönetimi için, Prometheus veri dizinini ayrı bir diskte (tercihen SSD) tutmak önemlidir. NFS gibi network dosya sistemleri kullanılmamalıdır; TSDB mmap kullanır ve network latency performansı ciddi şekilde etkiler. Wal (Write-Ahead Log) dizini de aynı diskte olmalıdır. Düzenli olarak promtool tsdb analyze komutu ile veri analizi yapılarak, gereksiz yüksek kardinaliteli metrikler tespit edilebilir.

# TSDB analizi
promtool tsdb analyze /var/lib/prometheus/

# Head block seri sayısı sorgusu
prometheus_tsdb_head_series

Yük Altında Ölçeklendirme Nasıl Sağlanır?

Prometheus'un tek instance'ı, ortalama 1 milyon aktif zaman serisini rahatlıkla işleyebilir. Ancak daha büyük ortamlarda, federation veya sharding gerekebilir. Federation'da, farklı Prometheus instance'ları farklı hedef gruplarını scrape eder ve merkezi bir Prometheus bu instance'ları sorgular. Bu, yük dağılımı sağlar ancak merkezi instance'a yük bindirir.

Sharding'de, hedefler hash fonksiyonu ile farklı Prometheus instance'larına dağıtılır. Her instance yalnızca kendi shard'ındaki hedefleri izler. Thanos Query Layer, bu dağıtık Prometheus'ları tek bir endpoint gibi sorgulamayı mümkün kılar. Bu mimari, milyonlarca zaman serisini ve yüzlerce hedefi yönetmek için idealdir. Özellikle SaaS platformlarında, her müşteri için ayrı shard kullanımı yaygın bir pratiktir.

# Federation scrape config
scrape_configs:
  - job_name: 'federate'
    scrape_interval: 15s
    honor_labels: true
    metrics_path: '/federate'
    params:
      'match[]':
        - '{job=~"prometheus.*"}'
    static_configs:
      - targets:
        - 'prometheus-dc1:9090'
        - 'prometheus-dc2:9090'

Uyumluluk ve Entegrasyon Senaryoları

Prometheus, tek başına bir izleme çözümü değil, geniş bir ekosistemin merkezidir. Exporter'lar, farklı sistemlerin ve uygulamaların metriklerini Prometheus formatına dönüştürür. Client kütüphaneleri, uygulama içinden özel metrikler üretmeyi kolaylaştırır. Alertmanager, bildirim yönetimini üstlenir. Grafana, görselleştirme katmanını oluşturur. Bu modüler yapı, mevcut altyapıya kolay entegrasyon sağlar.

CI/CD pipeline'larına entegre edilerek, deployment sonrası otomatik health check ve metrik doğrulama yapılabilir. Canary deployment'ların başarısını ölçmek, rollback kararlarını vermek için metrikler kritik rol oynar. E-ticaret ve SaaS uygulamalarında, iş metrikleri (satış, conversion, revenue) ile teknik metriklerin birlikte izlenmesi, hem operasyonel hem de iş kararlarını destekler.

CI/CD Pipeline ile İzleme Entegrasyonu

Modern deployment süreçlerinde, "deploy et ve unut" yaklaşımı yerini "deploy et ve izle"ye bıraktı. CI/CD pipeline'ına Prometheus sorguları entegre edilerek, yeni versiyonun sağlığı otomatik olarak doğrulanabilir. Argo Rollouts veya Flagger gibi progressive delivery araçları, Prometheus metriklerini kullanarak canary deployment'ların otomatik olarak promote veya rollback edilmesini sağlar.

Deployment sonrası, hata oranı ve latency metrikleri belirlenen eşiklerin altında kalıyorsa deployment onaylanır. Aksi halde otomatik rollback tetiklenir. Bu, test edilebilirlik ve güvenilirlik açısından büyük avantaj sağlar. GitOps yaklaşımıyla, izleme kuralları ve dashboard tanımları da versiyon kontrolünde tutularak, altyapı değişikliklerinin izlenebilirliği artırılır.

# Argo Rollouts analysis template
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
  - name: success-rate
    interval: 1m
    successCondition: result[0] >= 0.95
    provider:
      prometheus:
        address: http://prometheus:9090
        query: |
          sum(rate(http_requests_total{service="api"}[5m]))

E-Ticaret ve SaaS Uygulamalarında Metrik Kullanımı

E-ticaret platformlarında, teknik metriklerin ötesinde iş metrikleri izlenmelidir. Sepete ekleme oranı, ödeme başarısı, stok değişimi ve kullanıcı oturum süresi gibi metrikler, doğrudan geliri etkiler. Prometheus, bu metrikleri uygulama kodundan prometheus_client kütüphaneleri ile toplar. Örneğin, başarılı ve başarısız ödeme işlemleri ayrı Counter'lar ile takip edilir.

SaaS uygulamalarında, tenant bazlı metrikler (aktif kullanıcı sayısı, API kullanımı, storage tüketimi) kritiktir. Bu metrikler, hem teknik izleme hem de faturalandırma için kullanılabilir. Ancak tenant_id gibi yüksek kardinaliteli etiketler kullanılırken dikkatli olunmalıdır; çok fazla tenant, zaman serisi sayısını patlatabilir. Aggregation ve recording rules ile özetlenmiş metrikler oluşturmak daha sürdürülebilir bir yaklaşımdır.

# Python client örneği
from prometheus_client import Counter, Histogram

payment_total = Counter('payments_total', 'Toplam ödeme', ['status', 'currency'])
payment_duration = Histogram('payment_duration_seconds', 'Ödeme süresi')

@payment_duration.time()
def process_payment(amount, currency):
    # ödeme işlemi
    payment_total.labels(status='success', currency=currency).inc()

Diğer İzleme Araçları ve Exporter Uyumluluğu

Prometheus, OpenMetrics standardını destekler ve bu sayede birçok araçla uyumlu çalışır. Node Exporter, Linux sistem metriklerini toplar. cAdvisor, container metriklerini sunar. Blackbox Exporter, HTTP, DNS, TCP ve ICMP probe'ları yapar. JMX Exporter, Java uygulamalarının metriklerini dışa açar. Bu exporter'lar, mevcut altyapıyı sarmalayan bir izleme ağı oluşturur.

Datadog, New Relic gibi ticari çözümlerden Prometheus'a geçiş yapılırken, remote_write entegrasyonu ile paralel çalışma mümkündür. OpenTelemetry, metrik, log ve trace'leri birleştiren yeni bir standarttır ve Prometheus formatını destekler. Bu, distributed tracing (Jaeger, Tempo) ile metrik izlemenin birleştirilmesini sağlar. Profesyonel ekiplerde, çoklu araç kullanımı yerine standartlaşmış ve entegre çözümler tercih edilir.

# Blackbox exporter modülü
modules:
  http_2xx:
    prober: http
    timeout: 5s
    http:
      valid_http_versions: ["HTTP/1.1", "HTTP/2.0"]
      valid_status_codes: [200, 301, 302]

Uygulama Senaryoları ve Örnek Projeler

Prometheus'un esnekliği, onu farklı ölçek ve sektörlerdeki projelerde vazgeçilmez kılar. Startup'lardan küresel ölçekli platformlara kadar geniş bir kullanıcı kitlesi vardır. DigitalOcean, SoundCloud, Weaveworks gibi şirketler, Prometheus'u altyapılarının merkezine yerleştirmiştir. Bu başarı hikayeleri, aracın ölçeklenebilirlik ve güvenilirlik iddiasını destekler.

Proje başlangıcında doğru izleme stratejisi, ileride yaşanacak teknik borçları minimize eder. Prometheus, hem prototip aşamasında basit kurulumla hem de ürün büyüdükçe karmaşık dağıtık mimarilerle çalışabilir. Agile metodolojilerle uyumlu çalışır; sık iteration'lar ve değişen gereksinimler karşısında esnek metrik modeli sunar. Web geliştirme, mobil backend ve kurumsal sistemlerde farklı kullanım senaryoları vardır.

Web Geliştirme Projelerinde Performans İzleme Örnekleri

Web uygulamalarında, kullanıcı deneyimini doğrudan etkileyen metrikler izlenmelidir. Sayfa yükleme süresi (TTFB, FCP, LCP), API yanıt süreleri, veritabanı sorgu süreleri ve frontend hata oranları temel göstergelerdir. Prometheus, bu metrikleri uygulama sunucularından veya APM araçlarından toplar. Real User Monitoring (RUM) verileri, kullanıcıların gerçek deneyimini yansıtır.

Load balancer ve CDN metrikleri de izlenerek, altyapının tam görünürlüğü sağlanır. Örneğin, Nginx veya HAProxy exporter'ları ile trafik dağılımı, aktif bağlantılar ve backend sağlığı takip edilir. Bu veriler, performans optimizasyonu kararlarını destekler; önbellek stratejisini değiştirmek, CDN yapılandırmasını ayarlamak veya yeni sunucu ekleme gibi. Kullanıcı deneyimi metrikleri, teknik ekipler ile ürün ekipleri arasında ortak bir dil oluşturur.

# Nginx exporter metrik örneği
nginx_http_requests_total{status="200",method="GET"} 15420
nginx_http_requests_total{status="500",method="POST"} 12

# Frontend Core Web Vitals metrikleri
web_vitals_lcp_seconds_bucket{le="2.5"} 0.89
web_vitals_cls_score_bucket{le="0.1"} 0.95

Mobil Backend ve API Metrikleri Nasıl Toplanır?

Mobil uygulamalar, genellikle backend API'ler aracılığıyla veri alışverişi yapar. Bu API'lerin sağlığı, doğrudan mobil kullanıcı deneyimini etkiler. Prometheus, API gateway'ler (Kong, Ambassador, Istio) veya uygulama sunucuları üzerinden metrik toplar. Endpoint bazlı istek sayısı, latency dağılımı, hata oranları ve payload boyutları izlenir.

Rate limiting ve throttling metrikleri, API kötüye kullanımını tespit etmeye yardımcı olur. Kimlik doğrulama ve yetkilendirme hataları, güvenlik açısından kritiktir. Mobil uygulama versiyonlarına göre metrik ayrımı yapmak, eski versiyonlardaki hataları tespit etmeyi kolaylaştırır. Cross-platform mobil uygulamalarda (React Native, Flutter), backend metrikleri ile istemci metriklerinin birlikte analizi, sorunların kök nedenini bulmayı hızlandırır.

# API metrik middleware örneği (Flask)
from prometheus_client import Counter, Histogram

REQUEST_COUNT = Counter('api_requests_total', 'API requests', ['method', 'endpoint', 'status'])
REQUEST_LATENCY = Histogram('api_request_duration_seconds', 'Request latency', ['endpoint'])

@app.before_request
def before_request():
    request.start_time = time.time()

@app.after_request
def after_request(response):
    latency = time.time() - request.start_time
    REQUEST_COUNT.labels(method=request.method, endpoint=request.endpoint, status=response.status_code).inc()
    REQUEST_LATENCY.labels(endpoint=request.endpoint).observe(latency)
    return response

Kurumsal İzleme: SLA ve SLO Takibi Örnekleri

Kurumsal projelerde, Service Level Agreement (SLA) ve Service Level Objective (SLO) takibi, hem müşteri sözleşmelerinin hem de iç kalite standartlarının yönetimi için kritiktir. SLO'lar, belirli bir metriğin hedef değerini tanımlar (örneğin, API availability %99.9). Error budget, SLO'ya ulaşmak için tolerans gösterilebilecek hata payını ifade eder.

Prometheus, SLO metriklerini hesaplar ve error budget tüketimini izler. Örneğin, aylık error budget %0.1 ise ve bu değerin %80'i ilk haftada tüketildiyse, yeni deployment'lar durdurulabilir veya feature flag'ler kapatılabilir. Bu yaklaşım, "hiç hata olmamalı" yerine "kabul edilebilir hata payını yönetmeliyiz" anlayışını getirir. Profesyonel ekiplerde, SLO tabanlı izleme, teknik ekipler ile iş birimleri arasında ortak bir başarı kriteri oluşturur.

# SLO hesaplama örneği
- record: slo:api_availability:ratio
  expr: |
    sum(rate(http_requests_total{status!~"5.."}[30d]))
    /
    sum(rate(http_requests_total[30d]))

# Alert: Error budget %80 tüketildi
- alert: ErrorBudgetBurn
  expr: slo:api_availability:ratio < 0.999 and slo:api_availability:ratio > 0
  for: 1h

Araçlar, Exporter'lar ve Ekosistem

Prometheus ekosistemi, izleme altyapısının her katmanını kapsayan zengin bir araç setine sahiptir. Exporter'lar, metrik toplama ağını genişletir. Alertmanager, bildirim yönetimini merkezileştirir. Pushgateway, kısa ömürlü job'ların metriklerini alır. Various client kütüphaneleri, uygulama içi metrik üretimini standartlaştırır. Bu modüler yapı, ihtiyaç duyulmayan bileşenleri eklemeden, gerektiğinde güçlü yeteneklerin eklenmesini mümkün kılar.

Yedekleme ve felaket kurtarma, üretim ortamlarında göz ardı edilmemesi gereken konulardır. Prometheus'un local verisi yedeklenmeli ve kritik kurallar versiyon kontrolünde tutulmalıdır. Ekosistemdeki araçlar, operasyonel verimliliği ve geliştirici deneyimini önemli ölçüde etkiler. Doğru araç seçimi, uzun vadeli sürdürülebilirliği sağlar.

Node Exporter, cAdvisor ve Uygulama Exporter Örnekleri

Node Exporter, Linux sistem metriklerini (CPU, bellek, disk, ağ, dosya sistemi) toplayan en temel exporter'dır. Her bare metal veya VM sunucusunda çalıştırılması önerilir. cAdvisor, Docker container'larının kaynak kullanımını ve performans metriklerini sunar. Kubernetes ortamında kubelet üzerinden benzer metrikler elde edilir.

Uygulama exporter'ları, veritabanları (PostgreSQL Exporter, MySQL Exporter, Redis Exporter), message queue'lar (Kafka Exporter, RabbitMQ Exporter) ve cache sistemleri (Memcached Exporter) için mevcuttur. Bu exporter'lar, uygulama katmanının altındaki altyapı bileşenlerinin sağlığını izler. Blackbox Exporter ise, dışarıdan probe yaparak servislerin erişilebilirliğini kontrol eder. Her exporter'ın kendine özgü yapılandırma ve güvenlik ayarları vardır.

# Node exporter metrik örnekleri
node_cpu_seconds_total{mode="idle",cpu="0"} 384720.12
node_memory_MemAvailable_bytes 4.2e+09
node_filesystem_avail_bytes{device="/dev/sda1",fstype="ext4"} 8.5e+10

# cAdvisor container metrikleri
container_cpu_usage_seconds_total{name="api-container"} 452.3
container_memory_working_set_bytes{name="api-container"} 2.1e+08

Alertmanager Nedir ve Nasıl Yapılandırılır?

Alertmanager, Prometheus'tan gelen alarm'ları alır, gruplar, susturur (silence) ve yönlendirir (route). Birden fazla bildirim kanalına (Slack, PagerDuty, OpsGenie, webhook, e-posta) destek verir. Routing tree yapısı, alarm'ların severity, servis, ortam gibi etiketlere göre farklı ekiplere yönlendirilmesini sağlar.

Inhibition, bir alarm tetiklendiğinde ilgili diğer alarm'ların bastırılmasını sağlar. Örneğin, bir datacenter down olduğunda, o datacenter'daki tüm servis alarm'ları susturulabilir. Grouping, benzer alarm'ların tek bir bildirimde birleştirilmesini sağlar ve bildirim selini (notification spam) önler. Repeat interval ayarı, aynı alarm'ın ne sıklıkla tekrar bildirileceğini kontrol eder.

# alertmanager.yml
route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
  receiver: 'slack-notifications'
  routes:
  - match:
      severity: critical
    receiver: 'pagerduty-critical'

receivers:
- name: 'slack-notifications'
  slack_configs:
  - api_url: 'https://hooks.slack.com/services/xxx'
    channel: '#alerts'

Backup, Restore ve Veri Dışa Aktarma Araçları

Prometheus'un local TSDB verisi, promtool ile snapshot alınabilir. Snapshot, belirli bir anda veritabanının tutarlı kopyasını oluşturur. Bu dosya, farklı bir Prometheus instance'ına taşınarak restore edilebilir. Ancak snapshot, çalışan instance üzerinde alındığından, büyük veri setlerinde kısa bir performans etkisi olabilir.

Remote storage çözümleri (Thanos, Cortex), veriyi object storage'a (S3, GCS, Azure Blob) yazar ve bu sayede doğal olarak yedeklenmiş olur. PromQL sorguları ile elde edilen veri, HTTP API üzerinden JSON veya CSV formatında dışa aktarılabilir. Bu, raporlama ve analiz için kullanışlıdır. Düzenli backup testleri, felaket anında verinin gerçekten geri yüklenebildiğini doğrular.

# Snapshot alma
curl -X POST http://localhost:9090/api/v1/admin/tsdb/snapshot

# Snapshot dizini
/var/lib/prometheus/snapshots/20240508T163000Z-00Z/

# Veri dışa aktarma (PromQL ile)
curl -G http://localhost:9090/api/v1/query \
  --data-urlencode 'query=up{job="api"}' \
  --data-urlencode 'time=2024-05-08T16:30:00Z'

Sonuç ve En İyi Uygulamalar

Prometheus, modern altyapı izleme dünyasında standart haline gelmiş güçlü ve esnek bir platformdur. Pull modeli, PromQL gücü, geniş exporter ekosistemi ve Kubernetes ile olan doğal uyumu, onu vazgeçilmez kılar. Ancak başarılı bir izleme stratejisi, sadece aracı kurmakla değil, doğru metrikleri toplamak, anlamlı sorgular yazmak ve aksiyon alınabilir alarm'lar tasarlamakla mümkün olur.

İzleme, projenin başından itibaren planlanmalı ve geliştirme sürecinin bir parçası haline getirilmelidir. Sonradan eklenen izleme, genellikle eksik ve yetersiz kalır. Metrik isimlendirme standartları, etiketleme stratejileri ve dashboard tasarım ilkeleri, ekip içinde belirlenmeli ve dokümante edilmelidir. Bu disiplin, uzun vadede operasyonel verimliliği ve sistem güvenilirliğini artırır.

İzleme Stratejisi Rehberi: Başlangıç-Orta-İleri Adımlar

Başlangıç seviyesinde, temel sistem metrikleri (CPU, bellek, disk, ağ) ve uygulama sağlığı (up, memory usage) izlenmelidir. Node Exporter ve uygulama endpoint'leri kurularak hızlı bir başlangıç yapılır. Grafana'da basit dashboard'lar oluşturulur ve kritik hatalar için temel alarm'lar tanımlanır.

Orta seviyede, servis bazlı metrikler (API latency, error rate, throughput) eklenir. RED (Rate, Errors, Duration) ve USE (Utilization, Saturation, Errors) metodolojileri uygulanır. Alertmanager ile bildirim yönetimi kurulur ve on-call rotasyonları başlatılır. İleri seviyede, SLO tabanlı izleme, distributed tracing entegrasyonu, multi-cluster federation ve uzun vadeli depolama devreye alınır. Profesyonel ekiplerde, bu evrim doğal olarak projenin olgunlaşmasıyla birlikte gerçekleşir.

Gelecek Trendler: Ölçeklenebilir İzleme ve Yapay Zeka

Prometheus ekosistemi, sürekli olarak yeni yetenekler kazanıyor. OpenTelemetry entegrasyonu, metrik, log ve trace'leri tek bir standart altında birleştiriyor. Agent mode, Prometheus'u hafif bir agent olarak çalıştırarak edge computing senaryolarına uygun hale getiriyor. Native histogram'lar, daha verimli veri saklama ve sorgulama imkanı sunuyor.

Yapay zeka ve makine öğrenimi, izleme dünyasında da kendini gösteriyor. Anomali tespiti, seasonality analizi ve predictive alerting gibi yetenekler, Prometheus verisi üzerinde uygulanıyor. Cortex ve Thanos gibi projeler, global ölçekte metrik aggregation ve sorgulama sağlıyor. Gelecekte, izleme sistemleri sadece "ne oldu" sorusuna cevap vermekle kalmayıp, "ne olacak" ve "neden oldu" sorularına da yanıt verebilecek.

Web Geliştirme, Responsive Tasarım ve UI/UX Projelerine Katkıları

Modern web geliştirme, kullanıcı deneyimini merkeze alan bir yaklaşım gerektirir. Prometheus, Core Web Vitals ve API performans metrikleri ile bu deneyimin temelini oluşturur. Real-time dashboard'lar, geliştiricilere ve ürün yöneticilerine anlık görünürlük sağlar. A/B test sonuçlarının metriklerle desteklenmesi, data-driven karar almayı mümkün kılar.

Responsive tasarım prensipleri, izleme arayüzlerine de uygulanmalıdır. Mobil uyumlu Grafana dashboard'ları, on-call ekiplerin her an ve her yerden sisteme müdahale etmesini sağlar. Kullanıcı deneyimi metriklerinin teknik ekipler tarafından anlaşılması ve iş birimleriyle paylaşılması, organizasyonel sinerji yaratır. Noves Digital olarak, projelerimizde Prometheus'u bu bütünsel yaklaşımla kullanarak hem sistem sağlığını hem de kullanıcı memnuniyetini sürekli izliyor ve iyileştiriyoruz.