InfluxDB ve Prometheus Karşılaştırması: Hangisi Sizin İçin Doğru?

Tarafındankomut
0 Comments

Zaman serisi veritabanı dünyasına adım attığınızda, karşınıza çıkan iki büyük isim var: InfluxDB ve Prometheus. İkisi de monitoring ve metrik toplama işleri için tasarlanmış olsa da, mimari yaklaşımları, kullanım senaryoları ve operasyonel gereksinimleri açısından birbirinden ciddi şekilde ayrılıyor. Yıllarca her ikisini de production ortamlarında kullanan biri olarak söyleyebilirim ki, “hangisi daha iyi?” sorusunun cevabı tamamen ihtiyacınıza göre değişiyor. Bu yazıda her iki sistemi derinlemesine karşılaştırarak, hangi senaryoda hangisini tercih etmeniz gerektiğini somut örneklerle ele alacağım.

Temel Mimari Farklılıklar

İki sistemi anlamak için önce nasıl çalıştıklarını kavramak gerekiyor.

Prometheus bir “pull” modeliyle çalışır. Yani Prometheus sunucusu, izlemek istediğiniz hedeflere gidip metrikleri kendisi çeker. Bu hedefler HTTP üzerinden /metrics endpoint’i expose eder ve Prometheus belirlediğiniz aralıklarla bu endpoint’leri scrape eder. Bu yaklaşım, servislerin nerede çalıştığını merkezi bir yerden yönetmenizi sağlar.

InfluxDB ise tam tersi bir “push” modeliyle çalışır. Uygulamalarınız, ajanlar veya Telegraf gibi araçlar metrikleri doğrudan InfluxDB’ye gönderir. Sunucu pasif olarak veri bekler ve gelen her şeyi depolar. Bu yaklaşım özellikle firewall arkasındaki sistemlerden veya kısa ömürlü işlerden (batch jobs) veri toplamak için çok daha pratiktir.

Veri modeli açısından da önemli farklar var. Prometheus her şeyi label tabanlı bir sistemde saklar. Metrik adı ve label kombinasyonu bir time series oluşturur. InfluxDB ise measurement, tag ve field kavramlarıyla çalışır. Bu fark başta küçük görünse de, büyük ölçekte sistem tasarımını doğrudan etkiler.

Kurulum ve İlk Yapılandırma

Her ikisini de pratik olarak görelim.

Prometheus Kurulumu

# Prometheus binary indirme
wget https://github.com/prometheus/prometheus/releases/download/v2.48.0/prometheus-2.48.0.linux-amd64.tar.gz
tar xvf prometheus-2.48.0.linux-amd64.tar.gz
cd prometheus-2.48.0.linux-amd64/

# Sistem kullanıcısı oluşturma
sudo useradd --no-create-home --shell /bin/false prometheus
sudo mkdir /etc/prometheus /var/lib/prometheus

# Binary'leri kopyalama
sudo cp prometheus promtool /usr/local/bin/
sudo cp -r consoles/ console_libraries/ /etc/prometheus/
sudo chown -R prometheus:prometheus /etc/prometheus /var/lib/prometheus

Temel prometheus.yml yapılandırması:

# /etc/prometheus/prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

alerting:
  alertmanagers:
    - static_configs:
        - targets:
          - alertmanager:9093

rule_files:
  - "alert_rules.yml"

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

  - job_name: 'node_exporter'
    static_configs:
      - targets: ['web01:9100', 'web02:9100', 'db01:9100']
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance
        regex: '([^:]+):.*'
        replacement: '$1'

InfluxDB Kurulumu

# InfluxDB 2.x kurulumu (Ubuntu/Debian)
wget -q https://repos.influxdata.com/influxdata-archive_compat.key
echo '393e8779c89ac8d958f81f942f9ad7fb82a25e133faddaf92e15b16e6ac9ce4c influxdata-archive_compat.key' | sha256sum -c && cat influxdata-archive_compat.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/influxdata-archive_compat.gpg > /dev/null

echo 'deb [signed-by=/etc/apt/trusted.gpg.d/influxdata-archive_compat.gpg] https://repos.influxdata.com/debian stable main' | sudo tee /etc/apt/sources.list.d/influxdata.list

sudo apt-get update && sudo apt-get install influxdb2

# Servis başlatma
sudo systemctl enable influxdb
sudo systemctl start influxdb

# İlk kurulum
influx setup 
  --username admin 
  --password SuperGizliSifre123 
  --org myorg 
  --bucket metrics 
  --retention 30d 
  --force

Telegraf ile InfluxDB’ye veri gönderimi:

# /etc/telegraf/telegraf.conf
[agent]
  interval = "10s"
  round_interval = true
  metric_batch_size = 1000
  metric_buffer_limit = 10000
  flush_interval = "10s"

[[outputs.influxdb_v2]]
  urls = ["http://influxdb-server:8086"]
  token = "$INFLUX_TOKEN"
  organization = "myorg"
  bucket = "metrics"

[[inputs.cpu]]
  percpu = true
  totalcpu = true
  collect_cpu_time = false

[[inputs.mem]]

[[inputs.disk]]
  ignore_fs = ["tmpfs", "devtmpfs", "devfs", "iso9660", "overlay", "aufs", "squashfs"]

[[inputs.net]]
  interfaces = ["eth0", "eth1"]

Sorgu Dilleri: PromQL vs Flux

Bu, iki sistem arasındaki en belirgin farklardan biri. Doğru sorgu dilini seçmek, günlük operasyonel verimliliğinizi doğrudan etkiler.

PromQL fonksiyonel ve nispeten kompakt bir yapıya sahip. Özellikle anlık rate hesaplamaları ve agregasyonlar için çok güçlü.

# Son 5 dakikada CPU kullanım oranı
rate(node_cpu_seconds_total{mode="idle"}[5m])

# Web sunucularında 5xx hata oranı (istek başına)
sum(rate(http_requests_total{status=~"5.."}[5m])) by (instance)
/
sum(rate(http_requests_total[5m])) by (instance)

# 95. persentil response time
histogram_quantile(0.95, 
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le, instance)
)

Flux ise InfluxDB’nin kendi sorgu dili olup veri pipeline mantığıyla çalışır. Başta garip gelebilir ama bir kez alıştığınızda inanılmaz esneklik sunuyor.

// Son 1 saatte yüksek CPU kullanan hostlar
from(bucket: "metrics")
  |> range(start: -1h)
  |> filter(fn: (r) => r._measurement == "cpu")
  |> filter(fn: (r) => r._field == "usage_percent")
  |> filter(fn: (r) => r.cpu == "cpu-total")
  |> aggregateWindow(every: 5m, fn: mean, createEmpty: false)
  |> filter(fn: (r) => r._value > 80.0)
  |> group(columns: ["host"])
  |> last()
// Disk doluluk tahmini (linear regression)
from(bucket: "metrics")
  |> range(start: -7d)
  |> filter(fn: (r) => r._measurement == "disk")
  |> filter(fn: (r) => r._field == "used_percent")
  |> filter(fn: (r) => r.host == "db-primary")
  |> timedMovingAverage(every: 1h, period: 6h)
  |> holtWinters(n: 168, seasonality: 24, withFit: false)

Şunu açıkça söylemeliyim: PromQL, monitoring odaklı sorgular için çok daha hızlı yazılır. Flux ise daha karmaşık veri dönüşümleri ve analizler için üstün. Ekibinizin teknik seviyesine göre bu faktörü değerlendirin.

Gerçek Dünya Senaryosu: Kubernetes Cluster İzleme

Burada iki sistemin yaklaşımı arasındaki fark netleşiyor.

Kubernetes ortamında Prometheus, doğal habitat gibi çalışır. kube-state-metrics ve node-exporter kombinasyonuyla neredeyse kutudan çıkan haliyle harika bir monitoring altyapısı kurabilirsiniz. Prometheus Operator ile Kubernetes-native bir deployment yapabilir, ServiceMonitor CRD’leriyle yeni servisleri otomatik olarak discovery edebilirsiniz.

# Kubernetes'te Prometheus stack kurulumu (Helm ile)
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack 
  --namespace monitoring 
  --create-namespace 
  --set grafana.enabled=true 
  --set alertmanager.enabled=true 
  --set prometheus.prometheusSpec.retention=15d 
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.storageClassName=fast-ssd 
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=100Gi

Aynı senaryoda InfluxDB kullanmak isteseydiniz, Telegraf’ı DaemonSet olarak deploy etmeniz ve her node’dan veri toplamanız gerekirdi:

# telegraf-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: telegraf
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: telegraf
  template:
    metadata:
      labels:
        app: telegraf
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: telegraf
        image: telegraf:1.28
        env:
        - name: INFLUX_TOKEN
          valueFrom:
            secretKeyRef:
              name: influxdb-token
              key: token
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        volumeMounts:
        - name: telegraf-config
          mountPath: /etc/telegraf
        - name: varrunsystemd
          mountPath: /var/run/systemd
        - name: proc
          mountPath: /rootfs/proc
          readOnly: true
      volumes:
      - name: telegraf-config
        configMap:
          name: telegraf-config
      - name: varrunsystemd
        hostPath:
          path: /var/run/systemd
      - name: proc
        hostPath:
          path: /proc

Kubernetes monitoring için Prometheus ekosistemi çok daha olgun. ServiceMonitor, PodMonitor gibi kavramlarla yeni bir servis deploy ettiğinizde monitoring otomatik devreye girer. Bu konuda Prometheus’un avantajı tartışmasız.

Veri Saklama ve Performans

Uzun vadeli veri saklama ihtiyacınız varsa, iki sistem arasındaki fark kritik hale geliyor.

Prometheus’un local storage’ı iyi performans gösterir ancak uzun vadeli saklama için tasarlanmamıştır. Varsayılan 15 günlük retention sonrasında veriler silinir. Uzun vadeli saklama için Thanos veya Cortex gibi ek sistemler gerekir. Bu durum operasyonel karmaşıklığı artırır.

# Thanos sidecar kurulumu (Prometheus ile birlikte)
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

InfluxDB ise uzun vadeli saklama için tasarlanmıştır. Bucket’lar üzerinde retention policy tanımlayabilir, downsampling yapabilirsiniz. InfluxDB 2.x’in Tasks özelliği, veriyi belirli aralıklarla örnekleyerek daha az yer kaplamasını sağlar:

// Eski verileri downsampling yapan InfluxDB Task
option task = {
  name: "downsample_metrics",
  every: 1h,
  offset: 5m
}

data = from(bucket: "metrics")
  |> range(start: -task.every)
  |> filter(fn: (r) => r._measurement == "cpu" or r._measurement == "mem")
  |> aggregateWindow(every: 5m, fn: mean, createEmpty: false)

data |> to(bucket: "metrics_1year", org: "myorg")
# InfluxDB bucket ile uzun dönem retention yönetimi
influx bucket create 
  --name metrics_longterm 
  --org myorg 
  --retention 365d 
  --shard-group-duration 7d

# Mevcut bucket'ın retention'ını güncelleme
influx bucket update 
  --id YOUR_BUCKET_ID 
  --retention 90d

Büyük ölçekte InfluxDB, veri sıkıştırma konusunda da üstün performans gösterir. Özellikle IoT veya yüksek frekanslı metrik senaryolarında bu fark belirginleşir.

Alerting Mekanizmaları

Prometheus tarafında alerting, Alertmanager ile entegre çalışır. Alert kuralları PromQL ile tanımlanır ve son derece güçlüdür:

# alert_rules.yml
groups:
  - name: infrastructure
    rules:
      - alert: HighCPUUsage
        expr: |
          (100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 85
        for: 5m
        labels:
          severity: warning
          team: ops
        annotations:
          summary: "Yüksek CPU kullanımı: {{ $labels.instance }}"
          description: "{{ $labels.instance }} üzerinde CPU kullanımı {{ $value | printf "%.2f" }}% olarak ölçüldü."
          runbook: "https://wiki.internal/runbooks/high-cpu"

      - alert: DiskSpaceCritical
        expr: |
          (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 10
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Kritik disk doluluk: {{ $labels.instance }}"

InfluxDB tarafında alerting, Checks ve Notifications sistemiyle yapılır. InfluxDB 2.x’te bu özellik oldukça gelişmiş olmakla birlikte, Prometheus + Alertmanager kombinasyonu kadar esnek değil. Özellikle routing, silencing ve inhibition mekanizmaları açısından Alertmanager hala bir adım önde.

Hangi Senaryoda Hangisi?

Yıllarca her ikisini de kullandıktan sonra şu sonuçlara vardım:

Prometheus’u tercih edin eğer:

  • Kubernetes veya container-heavy bir ortamınız varsa
  • Pull modeli mimarinize daha uygunsa (target’larınıza network erişiminiz var)
  • Ekibiniz DevOps kültürüne yakınsa ve Grafana + Prometheus stack’ine alışkınsa
  • Short-lived işlerden değil, long-running servislerden metrik topluyorsanız
  • Alerting ihtiyaçlarınız karmaşık routing gerektiriyorsa
  • Open source ve topluluk desteği öncelikliyse

InfluxDB’yi tercih edin eğer:

  • IoT cihazlarından veya embedded sistemlerden veri topluyorsanız
  • Firewall arkasındaki sistemlerden veri almanız gerekiyorsa (push model avantajı)
  • Uzun vadeli veri saklama ve trend analizi öncelikliyse
  • Downsampling ve veri yaşam döngüsü yönetimi kritikse
  • Yüksek yazma throughput’u gerekiyorsa (saniyede 100k+ nokta)
  • SQL benzeri bir sorgu deneyimi veya Flux’un pipeline yaklaşımı daha uygunsa
  • Custom metrikler ve application-level monitoring ön plandaysa

Her ikisini birlikte kullanın eğer:

  • Hem infrastructure monitoring (Prometheus) hem de business metrics / IoT (InfluxDB) ihtiyacınız varsa. Bu aslında büyük organizasyonlarda oldukça yaygın bir kurulum.

Operasyonel Yönetim

Günlük operasyonel yükü karşılaştırdığımızda, Prometheus daha basit bir sistem. Tek binary, basit storage formatı, kolay backup/restore. Ancak scale ettikçe Thanos veya Cortex gibi sistemler gerekiyor ve bu karmaşıklığı artırıyor.

InfluxDB başlangıçta biraz daha karmaşık görünse de, özellikle 2.x sürümüyle gelen UI ve yönetim araçları operasyonel süreci kolaylaştırıyor. Backup konusunda her iki sistem de yeterli araçlar sunuyor:

# Prometheus data backup
# Önce snapshot al
curl -XPOST http://localhost:9090/api/v1/admin/tsdb/snapshot

# Snapshot'ı yedekle
rsync -av /var/lib/prometheus/data/snapshots/SNAPSHOT_NAME/ 
  backup-server:/backups/prometheus/$(date +%Y%m%d)/

# InfluxDB backup
influx backup 
  --bucket metrics 
  --org myorg 
  --token $INFLUX_TOKEN 
  /backup/influxdb/$(date +%Y%m%d)

# InfluxDB restore
influx restore 
  --bucket metrics 
  --org myorg 
  --token $INFLUX_TOKEN 
  /backup/influxdb/20240115

Resource Kullanımı

Production’da dikkat etmeniz gereken önemli bir nokta: Prometheus, yüksek cardinality durumlarında bellek tüketimi açısından tehlikeli olabilir. Çok fazla unique label kombinasyonu oluşturmak (high cardinality) Prometheus’u ciddi şekilde yavaşlatır. Bu yüzden label tasarımı kritik.

InfluxDB tarafında ise tag cardinality benzer şekilde dikkat gerektiriyor. Özellikle unbounded tag değerleri (user ID, session ID gibi) serisi patlamasına yol açabilir.

Her iki sistemde de resource limitleri tanımlamak iyi bir pratik:

# Prometheus systemd service ile memory limit
[Service]
ExecStart=/usr/local/bin/prometheus 
  --config.file=/etc/prometheus/prometheus.yml 
  --storage.tsdb.path=/var/lib/prometheus/ 
  --storage.tsdb.retention.time=15d 
  --storage.tsdb.retention.size=50GB 
  --web.enable-lifecycle 
  --web.enable-admin-api
MemoryMax=8G
CPUQuota=200%

Sonuç

InfluxDB ve Prometheus, farklı sorunları çözmek için tasarlanmış iki güçlü araç. “Hangisi daha iyi?” sorusunun cevabı yok, “Hangisi benim ihtiyacıma daha uygun?” sorusu var.

Eğer Kubernetes tabanlı, mikroservis mimarisi ağırlıklı bir ortam yönetiyorsanız ve pull model sizin için sorun değilse, Prometheus + Grafana + Alertmanager kombinasyonu hala sektörün en güçlü monitoring stack’i. Özellikle Kubernetes ekosistemiyle olan native entegrasyonu rakipsiz.

Eğer IoT projelerinde çalışıyorsanız, yüksek frekanslı veri topluyorsanız, uzun vadeli veri analizi yapmanız gerekiyorsa veya push modelinin mimarinize daha uyduğunu düşünüyorsanız, InfluxDB + Telegraf kombinasyonu size çok daha fazla esneklik ve uzun vadeli performans sunacak.

Pratik tavsiyem: Eğer yeni başlıyorsanız ve ağırlıklı olarak sunucu/container monitoring yapacaksanız Prometheus ile başlayın. Zaten çoğu monitoring dashboard ve exporter bu ekosistem üzerine kurulu. Özel uygulama metrikleri veya IoT ihtiyaçları ortaya çıktıkça InfluxDB’yi bu ekosisteme ek olarak devreye alabilirsiniz. İkisi birbirini dışlamıyor, birbirini tamamlıyor.

Bir yanıt yazın

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