Zabbix ile Prometheus Karşılaştırması: Hangisi Seçilmeli?

Yazar:komut.io ekibi Zabbix ile Sunucu İzleme ve Yönetimi
0 Yorum

Monitoring dünyasında iki büyük isim var: Zabbix ve Prometheus. Her ikisini de production ortamlarında yıllarca kullandım, birinden diğerine geçişleri yönettim, ikisini aynı anda çalıştırdım. Bu yazıda size “hangisi daha iyi?” sorusunun cevabını değil, “hangi durumda hangisini seçmelisiniz?” sorusunun cevabını vereceğim. Çünkü doğru soru bu.

Mimari Farklar: Neden Önemli?

Zabbix ve Prometheus’un temel farkı, veri toplama mimarisinde yatıyor. Bu fark, her şeyi etkiliyor: kurulum, ölçekleme, bakım, ekip adaptasyonu.

Zabbix push/pull hibrit model kullanıyor. Agent kurulmuş sunucular veri gönderebilir (active), Zabbix server da çekebilir (passive). Veritabanı merkezli bir yapı: tüm metrikler, konfigürasyonlar, kullanıcılar bir veritabanında (MySQL, PostgreSQL, Oracle) yaşıyor.

Prometheus ise saf pull model. Hedef endpointleri scrape ediyor, verileri kendi time-series veritabanında (TSDB) saklıyor. Konfigürasyon dosya tabanlı, veritabanı bağımlılığı yok.

Bu mimari fark pratikte şu anlama geliyor: Zabbix’te bir şeyi değiştirdiğinizde UI’dan yapıyorsunuz ve veritabanına yazılıyor. Prometheus’ta config dosyasını düzenliyorsunuz, reload atıyorsunuz. İkinci yaklaşım GitOps ve Infrastructure as Code ile çok daha iyi uyuşuyor.

Kurulum Karşılaştırması

Zabbix kurulumu biraz daha karmaşık. Veritabanı, server, frontend, agent bileşenlerini ayrı ayrı yönetiyorsunuz. Ama bu karmaşıklık beraberinde daha fazla kontrol getiriyor.

# Zabbix 6.4 kurulumu - Ubuntu 22.04
wget https://repo.zabbix.com/zabbix/6.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.4-1+ubuntu22.04_all.deb
dpkg -i zabbix-release_6.4-1+ubuntu22.04_all.deb
apt update

apt install -y zabbix-server-mysql zabbix-frontend-php 
    zabbix-apache-conf zabbix-sql-scripts zabbix-agent2

# Veritabanı oluşturma
mysql -u root -p -e "CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;"
mysql -u root -p -e "CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'StrongPass123!';"
mysql -u root -p -e "GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost';"

# Schema yükleme
zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | 
    mysql --default-character-set=utf8mb4 -uzabbix -p zabbix

systemctl enable --now zabbix-server zabbix-agent2 apache2

Prometheus tarafında işler çok daha basit:

# Prometheus kurulumu
PROM_VERSION="2.48.0"
wget https://github.com/prometheus/prometheus/releases/download/v${PROM_VERSION}/prometheus-${PROM_VERSION}.linux-amd64.tar.gz
tar xvf prometheus-${PROM_VERSION}.linux-amd64.tar.gz
mv prometheus-${PROM_VERSION}.linux-amd64 /opt/prometheus

# Servis kullanıcısı
useradd --no-create-home --shell /bin/false prometheus
chown -R prometheus:prometheus /opt/prometheus

# Temel config
cat > /opt/prometheus/prometheus.yml << 'EOF'
global:
  scrape_interval: 15s
  evaluation_interval: 15s

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

  - job_name: 'node'
    static_configs:
      - targets: ['web01:9100', 'web02:9100', 'db01:9100']
EOF

# Systemd unit
cat > /etc/systemd/system/prometheus.service << 'EOF'
[Unit]
Description=Prometheus
After=network.target

[Service]
User=prometheus
ExecStart=/opt/prometheus/prometheus 
    --config.file=/opt/prometheus/prometheus.yml 
    --storage.tsdb.path=/opt/prometheus/data 
    --storage.tsdb.retention.time=30d
Restart=always

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now prometheus

Gördüğünüz gibi Prometheus kurulumu gerçekten 10 dakika meselesi. Zabbix’te veritabanını ayarlamak, schema’yı yüklemek, frontend konfigürasyonu derken minimum 30-45 dakika harcıyorsunuz.

Metrik Toplama: Exporter vs Agent

Prometheus dünyasında exporter kavramı var. Her servis için ayrı bir exporter binary’si çalışıyor. node_exporter sistem metriklerini, mysqld_exporter MySQL metriklerini, nginx-exporter Nginx metriklerini topluyor.

# Node Exporter kurulumu
NODE_EXP_VERSION="1.7.0"
wget https://github.com/prometheus/node_exporter/releases/download/v${NODE_EXP_VERSION}/node_exporter-${NODE_EXP_VERSION}.linux-amd64.tar.gz
tar xvf node_exporter-${NODE_EXP_VERSION}.linux-amd64.tar.gz
mv node_exporter-${NODE_EXP_VERSION}.linux-amd64/node_exporter /usr/local/bin/

cat > /etc/systemd/system/node_exporter.service << 'EOF'
[Unit]
Description=Node Exporter
After=network.target

[Service]
User=prometheus
ExecStart=/usr/local/bin/node_exporter 
    --collector.systemd 
    --collector.processes 
    --web.listen-address=":9100"
Restart=always

[Install]
WantedBy=multi-user.target
EOF

systemctl enable --now node_exporter

Bu yaklaşımın güzel yanı: her exporter bağımsız, küçük, tek bir iş yapıyor. Zabbix’te ise her şey agent içinde halloluyor, ama bu bazen şişkin bir agent anlamına geliyor.

Zabbix Agent2 ile özel metrik toplama şöyle yapılıyor:

# Zabbix UserParameter ile özel metrik
# /etc/zabbix/zabbix_agent2.d/custom.conf

# Disk I/O bekleyen process sayısı
UserParameter=custom.disk.wait,ps aux | awk '{print $8}' | grep -c "D"

# Belirli bir servisin memory kullanımı (örnek: nginx)
UserParameter=custom.nginx.memory,ps aux | grep nginx | grep -v grep | awk '{sum += $6} END {print sum}'

# Java heap kullanımı (JMX olmadan)
UserParameter=custom.java.heap[*],java -cp /opt/scripts/HeapCheck.jar HeapCheck $1

Zabbix’te UserParameter ile istediğiniz her şeyi script’e döküp metrik haline getirebilirsiniz. Bu esneklik gerçekten güçlü. Prometheus exporter yazmak da zor değil ama ek geliştirme gerektiriyor.

Alerting Mekanizmaları

Zabbix’te alerting trigger tabanlı. Bir eşik aşıldığında trigger aktifleşiyor, action çalışıyor. Konfigürasyon UI üzerinden yapılıyor ve oldukça görsel.

Prometheus’ta ise Alertmanager ayrı bir bileşen. Alert kuralları YAML formatında, PromQL ile yazılıyor. Bu başlangıçta karmaşık gelebilir ama çok güçlü.

# Prometheus alert kuralı örneği
# /opt/prometheus/rules/system_alerts.yml
groups:
  - name: system
    interval: 30s
    rules:
      - alert: YuksekCPUKullanimi
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
        for: 5m
        labels:
          severity: warning
          team: infra
        annotations:
          summary: "{{ $labels.instance }} CPU kullanimi yuksek"
          description: "Son 5 dakikada CPU kullanimi %{{ $value | printf "%.1f" }} seviyesinde"

      - alert: DiskDolmakUzere
        expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 15
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }} disk dolmak uzere"
          description: "Kalan alan: %{{ $value | printf "%.1f" }}"

Bu alert tanımı git reponuzda yaşıyor, review süreçlerinden geçiyor, versiyonlanıyor. Zabbix’te bir trigger oluştururken UI’da tıklıyorsunuz ve bu değişiklik audit log’da kalıyor ama git history’nizde değil.

Alertmanager konfigürasyonu da dosya tabanlı:

# /opt/alertmanager/alertmanager.yml
global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.sirket.com:587'
  smtp_from: '[email protected]'

route:
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default'
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty-critical'
      continue: true
    - match:
        team: infra
      receiver: 'infra-team-slack'

receivers:
  - name: 'default'
    email_configs:
      - to: '[email protected]'

  - name: 'infra-team-slack'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/XXX/YYY/ZZZ'
        channel: '#infra-alerts'
        text: '{{ range .Alerts }}{{ .Annotations.description }}{{ end }}'

Zabbix’te media type konfigürasyonu UI’dan yapılıyor ve Slack, PagerDuty gibi entegrasyonlar için webhook desteği mevcut. Ancak karmaşık routing kuralları yazmak Zabbix’te biraz daha zahmetli. Zabbix 6.0 ile gelen problem suppression ve maintenance window özellikleri oldukça olgunlaşmış durumda.

Sorgu Dili: SQL vs PromQL

Bu noktada deneyimlerimden konuşacağım. Zabbix’te geçmişe yönelik veri sorgulamak için UI’dan gidiyorsunuz, grafikler çiziyorsunuz. API üzerinden data çekmek mümkün ama PromQL kadar esnek değil.

PromQL öğrenme eğrisi var, inkâr etmeyeyim. Ama öğrendikten sonra çok güçlü:

# Son 1 saatte en fazla CPU kullanan 5 instance
topk(5, 
  100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[1h])) * 100)
)

# Disk yazma hızı MB/s cinsinden
rate(node_disk_written_bytes_total{device="sda"}[5m]) / 1024 / 1024

# Network interface başına RX/TX oranı
irate(node_network_receive_bytes_total{device!="lo"}[5m]) * 8 / 1024 / 1024

# Bellek kullanım yüzdesi (buffer/cache hariç)
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

# HTTP istek başarı oranı (örnek: blackbox_exporter ile)
rate(probe_success{job="http_check"}[5m]) * 100

Bu sorgular Grafana dashboard’larınızda, alert kurallarınızda, recording rule’larınızda kullanılıyor. Bir kez PromQL’i kavradıktan sonra Zabbix’in query arayüzü kısıtlayıcı gelmeye başlıyor.

Ölçekleme: Küçük Ortam vs Büyük Ortam

Burada işler ilginçleşiyor ve genellikle karar noktası burası oluyor.

50’den az sunucu: Her iki araç da rahatlıkla çalışır. Zabbix burada avantajlı çünkü kurulumu tamamlandıktan sonra ekibin öğrenmesi daha kolay, UI intuitive.

50-500 sunucu arası: Her iki araç da yönetilebilir. Zabbix Proxy kullanmaya başlamanız gerekebilir. Prometheus burada gayet iyi çalışıyor.

500+ sunucu: Prometheus ve Thanos veya Cortex kombinasyonu çok daha mantıklı. Zabbix’i bu ölçekte çalıştırabilirsiniz ama veritabanı yönetimi, partitioning, history housekeeping gibi konularla ciddi zaman harcarsınız.

# Zabbix Proxy kurulumu (dağıtık deployment için)
apt install -y zabbix-proxy-mysql

# /etc/zabbix/zabbix_proxy.conf
Server=192.168.1.10          # Ana Zabbix Server IP
Hostname=proxy-dc2           # Proxy adı
DBHost=localhost
DBName=zabbix_proxy
DBUser=zabbix
DBPassword=ProxyPass456!

# Proxy SQLite ile (hafif seçenek, küçük lokasyonlar için)
apt install -y zabbix-proxy-sqlite3
# /etc/zabbix/zabbix_proxy.conf
ProxyMode=0                  # Active proxy
DBName=/var/lib/zabbix/zabbix_proxy.db

Prometheus federation ile büyük ortamlarda ölçekleme:

# Global Prometheus (merkez) - diğer Prometheus'lardan veri toplama
scrape_configs:
  - job_name: 'federate'
    scrape_interval: 15s
    honor_labels: true
    metrics_path: '/federate'
    params:
      'match[]':
        - '{job="node"}'
        - '{__name__=~"job:.*"}'
    static_configs:
      - targets:
          - 'prometheus-dc1:9090'
          - 'prometheus-dc2:9090'
          - 'prometheus-dc3:9090'

Gerçek Dünya Senaryoları

Senaryo 1: Geleneksel altyapı, karma OS ortamı

Bir müşterimizde 200’ü aşkın Windows ve Linux sunucu, 15 farklı uygulama tipi, merkezi bir NOC ekibi vardı. NOC ekibi teknik ama komut satırından çok UI seven insanlar. Burada tereddütsüz Zabbix seçtik. Windows agent kurulumu kolay, SNMP ile network cihazları dahil edildi, IPMI ile fiziksel sunucu sağlığı izlendi. NOC ekibi adaptasyonu 1 haftada tamamlandı.

Senaryo 2: Kubernetes üzerinde mikroservis

30 microservice, Kubernetes cluster, CI/CD pipeline’ı olan bir startup. Burada Prometheus + Grafana + Alertmanager stack’i. Her service kendi /metrics endpoint’ini expose ediyor. ServiceMonitor kaynakları ile yeni servisler otomatik discover ediliyor. Zabbix bu ortamda epey zorlanırdı çünkü dynamic service discovery Prometheus’un doğasında var.

# Kubernetes ServiceMonitor örneği (Prometheus Operator)
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: uygulama-api
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: uygulama-api
  endpoints:
    - port: metrics
      interval: 15s
      path: /metrics
  namespaceSelector:
    matchNames:
      - production
      - staging

Senaryo 3: Hibrit yaklaşım

Bazı ortamlarda ikisini birden kullandım. Zabbix legacy sistemler ve network ekipmanları için, Prometheus ise Kubernetes workload’ları için. İkisinin verilerini Grafana’da birleştirip unified dashboard oluşturduk. Bu düşündüğünüzden daha iyi çalışıyor.

Öğrenme Eğrisi ve Ekip Faktörü

Dürüst olmak gerekirse, ekibinizin mevcut becerileri seçimi büyük ölçüde belirler.

Ekibinizde YAML yazabilen, git kullanan, terminal’den korkmayan insanlar varsa Prometheus stack’i benimsemek kolay. DevOps kültürü oturmuş bir ekip için Prometheus daha doğal hissettiriyor.

Ama NOC odaklı, vardiyalı çalışan, UI’dan operasyon yapan bir ekip için Zabbix çok daha kullanılabilir. Zabbix’in problem management, acknowledgment, escalation özellikleri gerçekten olgunlaşmış.

Maliyet ve Lisans

Her ikisi de open source ve ücretsiz. Ancak enterprise özellikler için:

  • Zabbix: Tamamen açık kaynak, ticari destek için Zabbix LLC’ye ödeme yapıyorsunuz. Kod her zaman bedava.
  • Prometheus: Apache 2.0 lisanslı. Grafana Cloud, Grafana Enterprise gibi ticari ürünler üzerine kurulu.

Büyük ölçekte Zabbix’in veritabanı maliyetleri gözden kaçırılmamalı. Yüksek write throughput için güçlü bir veritabanı sunucusu gerekiyor. Prometheus’un local TSDB’si bu açıdan çok daha verimli.

Monitoring as Code

Bu başlık altında Prometheus’un ciddi avantajı var. Tüm konfigürasyon dosya tabanlı olduğu için:

# Prometheus konfigürasyonunu test etme
/opt/prometheus/promtool check config /opt/prometheus/prometheus.yml

# Alert kurallarını test etme
/opt/prometheus/promtool check rules /opt/prometheus/rules/*.yml

# Unit test yazabilirsiniz alert kuralları için!
cat > /opt/prometheus/rules/tests/cpu_alert_test.yml << 'EOF'
rule_files:
  - ../system_alerts.yml

tests:
  - interval: 1m
    input_series:
      - series: 'node_cpu_seconds_total{mode="idle", instance="web01"}'
        values: '0+0.1x10 0+0.05x20'
    alert_rule_test:
      - eval_time: 10m
        alertname: YuksekCPUKullanimi
        exp_alerts:
          - exp_labels:
              instance: web01
              severity: warning
EOF

/opt/prometheus/promtool test rules /opt/prometheus/rules/tests/cpu_alert_test.yml

Zabbix bu konuda yakın zamana kadar oldukça geride kalıyordu. Zabbix 6.x ile configuration export/import API’si gelişti ama hâlâ Prometheus’un dosya tabanlı yaklaşımının yakalayabildiği IaC olgunluğunda değil. Terraform Zabbix provider mevcut ama deneyimlerim karışık.

Karar Kriterleri Özeti

Aşağıdaki sorulara verdiğiniz cevaplara göre karar verin:

  • Kubernetes veya container tabanlı ortam mı? Prometheus seçin.
  • Dynamic service discovery ihtiyacınız var mı? Prometheus üstün.
  • Windows ağırlıklı ortam mı? Zabbix daha kolay yönetilir.
  • NOC ekibi UI’dan çalışıyor mu? Zabbix kazanır.
  • GitOps ve IaC kültürü oturduysa? Prometheus daha uygun.
  • SNMP ile network cihazı izlemek istiyor musunuz? Zabbix çok daha hazır.
  • 500+ node, uzun vadeli metric saklama? Prometheus + Thanos kombinasyonu.
  • Hızlı kurulum, minimum öğrenme eğrisi? Zabbix (altyapı tarafı), Prometheus (uygulama tarafı karmaşıklaşabilir).

Sonuç

Yıllarca “Zabbix mi Prometheus mu?” tartışmasının içinde bulundum. Sonunda şunu fark ettim: bu sorunun tek bir doğru cevabı yok ve bu cevabı arayanlar genellikle yanlış soruyu soruyorlar.

Zabbix, altyapı izlemenin proven bir aracı. Olgun, kararlı, UI’sı güçlü, SNMP ve IPMI desteği mükemmel. Özellikle geleneksel datacenter ortamlarında, karma işletim sistemi ekosistemlerinde ve NOC ekipleriyle çalışırken rakipsiz.

Prometheus ise modern cloud-native dünyasının izleme standardı haline geldi. Kubernetes ekosistemiyle entegrasyonu, dosya tabanlı konfigürasyonu, güçlü sorgu dili ve aktif topluluğuyla yeni nesil altyapılarda tercih edilen araç.

Bugün yeni bir monitoring altyapısı kuruyorsanız ve ortamınız container/Kubernetes ağırlıklıysa Prometheus stack’i ile başlayın. Geleneksel sunucu parkı yönetiyorsanız ve ekibiniz UI odaklıysa Zabbix ile gidin. Büyük ve karma ortamlarda ikisini birden kullanmaktan çekinmeyin, Grafana her ikisini de datasource olarak destekliyor ve unified dashboarding yapabilirsiniz.

En kötü karar, ikisinden birini körü körüne seçip ortamınıza uydurmaya çalışmaktır. Araç ortama hizmet eder, ortam araca değil.

Bir yanıt yazın

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