Prometheus Veri Saklama: Retention ve Uzak Depolama Yapılandırması

Bykomut

Prometheus kurulumu yapıp metrikleri toplamaya başladığınızda, çok geçmeden şu soruyla yüz yüze gelirsiniz: “Bu veriler nereye gidiyor, ne kadar süre tutuluyor, disk dolmaya başlarsa ne yapacağım?” Varsayılan ayarlarla çalışan bir Prometheus sunucusu, veriyi 15 gün boyunca yerel diskinde saklar. Küçük bir ortam için bu yeterli olabilir ama üretim ortamlarında, özellikle uzun vadeli trend analizi yapmak istediğinizde bu süre hiç yetmez. Bu yazıda Prometheus’un veri saklama mekanizmasını, retention ayarlarını ve uzak depolama seçeneklerini gerçek dünya senaryolarıyla ele alacağız.

Prometheus’un Veri Depolama Mimarisi

Prometheus, topladığı zaman serisi verilerini TSDB (Time Series Database) adı verilen kendi özel veritabanına yazar. Bu veritabanı --storage.tsdb.path parametresiyle belirlenen dizinde tutulur, varsayılan olarak bu dizin ./data klasörüdür.

TSDB’nin çalışma mantığını anlamak, retention ayarlarını doğru yapılandırmak için kritik. Gelen metrikler önce bellekteki bir WAL (Write-Ahead Log) yapısına yazılır. Yaklaşık 2 saatlik veri biriktikten sonra bu veriler diske, block adı verilen değiştirilemez segmentlere yazılır. Her block kendi dizininde meta verisi, index dosyası ve chunk dosyalarıyla birlikte durur. Zamanla eski blocklar compaction işlemiyle birleştirilir ve bu sayede disk kullanımı optimize edilir.

# TSDB veri dizininin yapısını inceleyelim
ls -lh /var/lib/prometheus/data/

# Örnek çıktı:
# drwxr-xr-x 3 prometheus prometheus 4.0K 01HXYZ... (block dizinleri)
# drwxr-xr-x 2 prometheus prometheus 4.0K wal/
# -rw-r--r-- 1 prometheus prometheus  123 lock

# Bir block dizininin içine bakış
ls -lh /var/lib/prometheus/data/01HXYZ.../
# chunks/   index   meta.json   tombstones

Bu mimariyi anladıktan sonra retention ayarlarına geçebiliriz.

Retention Ayarları: Veriyi Ne Kadar Süre Tutacaksınız?

Prometheus’ta iki farklı retention parametresi var ve ikisinin birlikte nasıl çalıştığını bilmek önemli.

–storage.tsdb.retention.time: Verilerin ne kadar süre tutulacağını belirler. Varsayılan değer 15d yani 15 gün. Bu süreyi geçen blocklar otomatik olarak silinir.

–storage.tsdb.retention.size: Belirtilen disk boyutuna ulaşıldığında en eski blocklar silinir. Varsayılan olarak devre dışıdır (0). 1GB, 10GB, 100GB gibi değerler alır.

Bu iki parametre birlikte çalışır; hangisi önce tetiklenirse o koşul uygulanır. Yani retention.time 90 günse ama retention.size 10GB’a ulaştıysa, 90 gün dolmadan da eski veriler silinmeye başlar.

# Prometheus'u özel retention ayarlarıyla başlatmak
/usr/local/bin/prometheus 
  --config.file=/etc/prometheus/prometheus.yml 
  --storage.tsdb.path=/var/lib/prometheus/data 
  --storage.tsdb.retention.time=90d 
  --storage.tsdb.retention.size=50GB 
  --web.listen-address=":9090"

Systemd ile çalışıyorsanız, bu parametreleri service dosyasına eklemeniz gerekir:

# /etc/systemd/system/prometheus.service
[Unit]
Description=Prometheus Monitoring System
After=network.target

[Service]
Type=simple
User=prometheus
Group=prometheus
ExecStart=/usr/local/bin/prometheus 
    --config.file=/etc/prometheus/prometheus.yml 
    --storage.tsdb.path=/var/lib/prometheus/data 
    --storage.tsdb.retention.time=90d 
    --storage.tsdb.retention.size=50GB 
    --web.console.libraries=/usr/share/prometheus/console_libraries 
    --web.console.templates=/usr/share/prometheus/consoles 
    --web.listen-address=":9090"
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
# Değişiklikleri uygulamak için
sudo systemctl daemon-reload
sudo systemctl restart prometheus

# Retention ayarlarını doğrulamak
curl -s http://localhost:9090/api/v1/status/tsdb | python3 -m json.tool

Disk Boyutu Hesabı

“90 günlük veri için kaç GB disk ayırmalıyım?” sorusu her sysadmin’in sorduğu şey. Kabaca bir hesap yapmak mümkün. Prometheus, sıkıştırılmış haliyle scrape başına ortalama 1-2 byte kullanır. Ama bu rakam metrik sayısına, scrape interval’ına ve cardinality’ye göre değişir.

Şöyle düşünelim: 50 node, her node’da 1000 metrik, 30 saniyelik scrape interval ile 90 günlük veri için;

50 node x 1000 metrik x 2 byte x (86400/30 scrape/gün) x 90 gün
= 50 x 1000 x 2 x 2880 x 90
= yaklaşık 25.9 GB

Gerçek hayatta bu rakam genellikle daha düşük çıkar çünkü TSDB sıkıştırması oldukça etkili. Ama tahmin olarak 2 katını reserve etmek akıllıca.

Uzak Depolama: Long-Term Retention İçin Doğru Yol

Yerel retention’ın sınırlı olduğu durumlarda devreye Remote Storage giriyor. Prometheus’un uzak depolama entegrasyonu iki yönde çalışır:

remote_write: Prometheus topladığı verileri uzak bir depolama sistemine gönderir. remote_read: Sorgular yapılırken uzak depolamadan veri okunur.

Bu iki mekanizma sayesinde Prometheus hem yerel hem uzak depolama üzerinde şeffaf bir şekilde çalışabilir.

Neden Uzak Depolama Kullanmalısınız?

  • Uzun vadeli analiz: 1 yıl, 2 yıl önceki trendlere bakabilmek
  • HA (Yüksek Erişilebilirlik): Prometheus sunucusu çökse bile veriler kaybolmaz
  • Ölçeklendirme: Birden fazla Prometheus instance’ının verilerini tek yerde toplamak
  • Maliyet optimizasyonu: Eski verileri daha ucuz depolamaya taşımak

Thanos ile Uzak Depolama

Thanos, Prometheus ekosisteminde uzak depolama için en yaygın kullanılan çözümlerden biri. Object storage (S3, GCS, Azure Blob) üzerine kurulu, Prometheus ile sidecar pattern’ıyla entegre oluyor.

Thanos Sidecar kurulumu:

# Thanos sidecar, Prometheus'un yanında çalışır
# ve TSDB bloklarını object storage'a yükler

thanos sidecar 
  --tsdb.path=/var/lib/prometheus/data 
  --prometheus.url=http://localhost:9090 
  --grpc-address=0.0.0.0:10901 
  --http-address=0.0.0.0:10902 
  --objstore.config-file=/etc/thanos/objstore.yml

# S3 için objstore.yml örneği:
# /etc/thanos/objstore.yml
# /etc/thanos/objstore.yml
type: S3
config:
  bucket: "prometheus-long-term"
  endpoint: "s3.amazonaws.com"
  region: "eu-central-1"
  access_key: "AKIAIOSFODNN7EXAMPLE"
  secret_key: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
  insecure: false

Thanos ile çalışırken Prometheus’un retention süresini kısa tutabilirsiniz (örneğin 2-3 gün), çünkü uzun vadeli veriler object storage’da duruyor. Bu hem maliyet hem de performans açısından avantajlı.

VictoriaMetrics ile Uzak Depolama

VictoriaMetrics, Prometheus uyumlu, yüksek performanslı bir zaman serisi veritabanı. Remote write endpoint’i Prometheus ile tamamen uyumlu, kurulumu son derece basit.

# VictoriaMetrics tek binary ile çalışır
# İndirip başlatmak yeterli

wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.95.1/victoria-metrics-linux-amd64-v1.95.1.tar.gz
tar -xzf victoria-metrics-linux-amd64-v1.95.1.tar.gz

./victoria-metrics-prod 
  -storageDataPath=/var/lib/victoriametrics 
  -retentionPeriod=12 
  -httpListenAddr=:8428

Prometheus tarafında remote_write konfigürasyonu:

# /etc/prometheus/prometheus.yml

global:
  scrape_interval: 30s
  evaluation_interval: 30s

remote_write:
  - url: "http://victoriametrics:8428/api/v1/write"
    queue_config:
      max_samples_per_send: 10000
      max_shards: 30
      capacity: 100000
    write_relabel_configs:
      - source_labels: [__name__]
        regex: "go_.*"
        action: drop  # İstemediğiniz metrikleri filtreleyebilirsiniz

remote_read:
  - url: "http://victoriametrics:8428/api/v1/read"
    read_recent: true

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]

Remote Write Performans Ayarları

Remote write’ın production’da sağlıklı çalışması için queue_config parametrelerini iyi anlamak gerekiyor. Yanlış ayarlanmış bir queue hem Prometheus belleğini tüketir hem de veri kaybına yol açabilir.

capacity: Queue’da tutulabilecek maksimum sample sayısı. Bu değer yüksek tutulursa bellek tüketimi artar ama burst trafiği absorbe edilir.

max_shards: Paralel gönderim için kullanılan shard sayısı. Network gecikmeleri yüksekse bu değeri artırmak throughput’u iyileştirir.

min_shards: Başlangıç shard sayısı.

max_samples_per_send: Tek seferde gönderilecek maksimum sample sayısı.

batch_send_deadline: Batch dolmasa bile bu süre sonunda gönderim yapılır.

remote_write:
  - url: "http://victoriametrics:8428/api/v1/write"
    remote_timeout: 30s
    queue_config:
      capacity: 100000
      max_shards: 50
      min_shards: 1
      max_samples_per_send: 5000
      batch_send_deadline: 5s
      min_backoff: 30ms
      max_backoff: 5s
    tls_config:
      insecure_skip_verify: false
    basic_auth:
      username: "prometheus"
      password: "guclu-bir-sifre"

Remote write’ın ne durumda olduğunu Prometheus metrikleriyle takip edebilirsiniz:

# Remote write lag durumunu kontrol et
curl -s "http://localhost:9090/api/v1/query?query=prometheus_remote_storage_samples_pending" | python3 -m json.tool

# Başarısız gönderimleri izle
curl -s "http://localhost:9090/api/v1/query?query=rate(prometheus_remote_storage_failed_samples_total[5m])" | python3 -m json.tool

# Queue doluluğunu kontrol et
curl -s "http://localhost:9090/api/v1/query?query=prometheus_remote_storage_queue_highest_sent_timestamp_seconds" | python3 -m json.tool

Gerçek Dünya Senaryosu: E-ticaret Platformu Örneği

Diyelim ki 30 uygulama sunucusu, 10 veritabanı sunucusu ve 5 load balancer’dan oluşan bir e-ticaret platformunu yönetiyorsunuz. Altyapı ekibiniz her yıl sona yakın “geçen yılın Black Friday trafiği nasıldı?” sorusunu sormaya başlıyor ve siz Prometheus’ta sadece 15 günlük veri görebiliyorsunuz.

Çözüm: Prometheus’ta kısa retention (7 gün, anlık analiz için), VictoriaMetrics’te uzun retention (2 yıl, trend analizi için).

# /etc/prometheus/prometheus.yml - Üretim yapılandırması
global:
  scrape_interval: 15s
  evaluation_interval: 15s
  external_labels:
    cluster: "production"
    datacenter: "istanbul-dc1"

remote_write:
  - url: "http://victoriametrics.internal:8428/api/v1/write"
    queue_config:
      capacity: 200000
      max_shards: 100
      max_samples_per_send: 10000
    write_relabel_configs:
      # Sadece önemli metrikleri uzak depolamaya gönder
      - source_labels: [__name__]
        regex: "(http_requests_total|node_cpu_seconds_total|node_memory_MemAvailable_bytes|pg_stat_database_.*)"
        action: keep

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"]

rule_files:
  - "/etc/prometheus/rules/*.yml"

scrape_configs:
  - job_name: "app-servers"
    static_configs:
      - targets:
          - "app01:9100"
          - "app02:9100"
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance

Bu senaryo için Prometheus systemd servisini de güncelleyelim:

# Kısa yerel retention - anlık debugging için yeterli
ExecStart=/usr/local/bin/prometheus 
    --config.file=/etc/prometheus/prometheus.yml 
    --storage.tsdb.path=/var/lib/prometheus/data 
    --storage.tsdb.retention.time=7d 
    --storage.tsdb.retention.size=20GB 
    --web.listen-address=":9090" 
    --storage.tsdb.wal-compression

--storage.tsdb.wal-compression parametresi WAL dosyalarını sıkıştırır, disk kullanımını yüzde 40-60 oranında azaltabilir. Üretim ortamlarında mutlaka etkinleştirin.

TSDB Yönetimi ve Bakım İşlemleri

Prometheus Admin API’si aracılığıyla TSDB üzerinde bazı bakım işlemleri yapabilirsiniz. Bu API varsayılan olarak kapalıdır, etkinleştirmek için --web.enable-admin-api parametresi gerekir.

# Admin API'yi etkinleştirerek başlatmak
/usr/local/bin/prometheus 
    --config.file=/etc/prometheus/prometheus.yml 
    --web.enable-admin-api 
    --storage.tsdb.retention.time=90d

# TSDB anlık görüntü (snapshot) almak
# Backup senaryolarında kullanışlı
curl -XPOST http://localhost:9090/api/v1/admin/tsdb/snapshot

# Belirli bir zaman serisini silmek (GDPR, hassas veri silme vb.)
curl -XPOST 
  -H "Content-Type: application/x-www-form-urlencoded" 
  -d 'match[]=some_sensitive_metric{instance="server01"}' 
  http://localhost:9090/api/v1/admin/tsdb/delete_series

# Tombstone'ları temizlemek (silinen verilerin fiziksel olarak kaldırılması)
curl -XPOST http://localhost:9090/api/v1/admin/tsdb/clean_tombstones

Compaction ve Block Yönetimi

Prometheus’un otomatik compaction işlemi çoğunlukla yeterli olur. Ama zaman zaman blockları manuel olarak incelemeniz gerekebilir:

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

# Çıktıda şunlara bakın:
# - En yüksek cardinality'li metrikler
# - En fazla disk kullanan label kombinasyonları
# - Block sağlık durumu

# TSDB block listesi
promtool tsdb list /var/lib/prometheus/data

# Spesifik bir block'u dump etmek
promtool tsdb dump /var/lib/prometheus/data 
  --min-time=1700000000000 
  --max-time=1700100000000 | head -50

Retention Optimizasyonu: Recording Rules

Uzun vadeli veri tutarken tüm raw verileri saklamak hem pahalı hem de gereksiz. Recording Rules kullanarak, sık sorgulanan ifadeleri önceden hesaplanmış metrikler olarak saklayabilirsiniz. Hem sorgu performansı artar hem de uzak depolamaya gönderilen veri miktarı azalır.

# /etc/prometheus/rules/recording_rules.yml
groups:
  - name: aggregated_metrics
    interval: 5m
    rules:
      # Node başına CPU kullanım ortalaması (5 dakikalık)
      - record: job:node_cpu_usage:avg5m
        expr: |
          100 - (avg by (instance, job) (
            rate(node_cpu_seconds_total{mode="idle"}[5m])
          ) * 100)

      # HTTP request rate - servis bazında
      - record: job:http_requests:rate5m
        expr: |
          sum by (job, status_code) (
            rate(http_requests_total[5m])
          )

      # Memory kullanım yüzdesi
      - record: job:node_memory_usage:percent
        expr: |
          (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

Bu recording rules ile oluşturulan metrikler hem yerel Prometheus’ta hem de uzak depolamada saklanır. Raw metrikler yerel’de 7 gün tutulurken, aggregated metrikler uzakta 2 yıl tutulabilir. Bu şekilde hem maliyet hem de storage kapasitesi optimize edilmiş olur.

Monitoring the Monitoring: Prometheus’u İzlemek

Retention ve uzak depolama sağlığını takip etmek için kendi Prometheus instance’ınızı da izlemeniz gerekir.

# /etc/prometheus/rules/prometheus_health.yml
groups:
  - name: prometheus_health
    rules:
      - alert: PrometheusStorageSpaceRunningOut
        expr: |
          (node_filesystem_avail_bytes{mountpoint="/var/lib/prometheus"} /
           node_filesystem_size_bytes{mountpoint="/var/lib/prometheus"}) * 100 < 20
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Prometheus storage alanı azalıyor"
          description: "Prometheus disk kullanımı %80'i geçti"

      - alert: PrometheusRemoteWriteFailing
        expr: |
          rate(prometheus_remote_storage_failed_samples_total[5m]) > 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Remote write başarısız"
          description: "{{ $labels.instance }} remote write hataları alıyor"

      - alert: PrometheusRemoteWriteLag
        expr: |
          (time() - prometheus_remote_storage_queue_highest_sent_timestamp_seconds) > 120
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Remote write gecikmesi yüksek"
          description: "Remote write 2 dakikadan fazla gecikme yaşıyor"

Pratik Öneriler ve Yaygın Hatalar

Yıllar içinde gördüğüm en yaygın hataları ve çözümlerini paylaşayım:

  • Cardinality patlaması: Label olarak user_id, request_id gibi yüksek cardinality’li değerler kullanmak hem disk hemde bellek tüketimini patlatır. Recording rules ile aggregation yapın, raw high-cardinality metrikleri uzak depolamaya göndermeyin.
  • Remote write backpressure: Uzak depolama yavaşladığında Prometheus queue’su şişer ve bellek tüketimi artar. queue_config.capacity değerini ve Prometheus bellek limitini birlikte değerlendirin.
  • WAL boyutu: Prometheus yeniden başlatılırken WAL replay süresi uzun olabilir. WAL sıkıştırması (--storage.tsdb.wal-compression) bu süreyi kısaltır.
  • Snapshot almadan retention değiştirme: Retention süresini kısaltmadan önce mutlaka snapshot alın. curl -XPOST http://localhost:9090/api/v1/admin/tsdb/snapshot komutu yeterli.
  • Remote storage olmadan uzun retention: 365 günlük retention’ı doğrudan Prometheus’ta tutmaya çalışmak performans sorunlarına yol açar. 90 günü aşan retention için remote storage neredeyse zorunlu.
  • Tek Prometheus ile HA yapmaya çalışmak: Retention ne kadar uzun olursa olsun, tek bir Prometheus instance’ı HA sağlamaz. Thanos veya VictoriaMetrics cluster kurulumu düşünün.

Sonuç

Prometheus’ta veri saklama stratejisi, altyapınızın büyüklüğüne ve ihtiyaçlarınıza göre şekillenmeli. Küçük bir ortam için --storage.tsdb.retention.time=30d ile başlamak yeterli olabilir. Ama üretim ortamlarında, özellikle SLA gerektiren sistemlerde, yerel kısa retention artı uzak depolama kombinasyonu altın standart haline geldi.

VictoriaMetrics ile başlamak en kolay yol: tek binary, Prometheus ile tam uyumlu, sıkıştırma oranı Prometheus TSDB’den yüzde 5-10 daha iyi. Daha karmaşık multi-cluster senaryolarında veya object storage entegrasyonu gerektiğinde Thanos’a geçmek mantıklı.

Sonuç olarak şunu söyleyebilirim: retention ayarlarını bir kez yapıp unutmayın. Düzenli olarak promtool tsdb analyze çıktısını inceleyin, disk kullanımını izleyin, remote write lag’ini takip edin. Monitoring altyapısının kendisi de izlenmesi gereken bir sistem. Bunu sağladığınızda “geçen yılın Black Friday’i nasıldı?” sorusuna birkaç saniyede cevap verebilirsiniz.

Benzer Konular

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir