İçeriğe geç
Zabbix

Zabbix; 2001’den bu yana geliştirilen, kurumsal altyapı izleme için olgun ve özellik-zengin açık-kaynak çözümdür. Tek bir kurulum binlerce host’u, sunucudan ağ ekipmanına, ortam sensöründen iş uygulamasına kadar izleyebilir. Türkiye’de telekom, kamu, finans ve enerji sektörlerindeki büyük operasyon merkezlerinin neredeyse tamamında Zabbix temel izleme aracı olarak kullanılmaktadır.

Modern bulut-yerel Prometheus + Grafana yığınının aksine, Zabbix tek bir bütün olarak gelir: veri toplama (agent + agentless), veritabanı, trigger motoru, bildirim sistemi ve web UI. Bu, “hızlı kur, kullan” yaklaşımı isteyen kurumlar için ciddi bir avantaj.

Mono’nun yaklaşımı

Mono ekibi Zabbix’i 1500+ host’lu kurumsal kurulumlardan, KOBİ ölçeklerine kadar yöneter. Standart kararlarımız:

  • Versiyon: Zabbix 7.0 LTS veya 7.4 (yeni).
  • Veritabanı: TimescaleDB (PostgreSQL extension’ı) zorunlu — büyük history tabloları için sıkıştırma + partition.
  • Topology: Tek server + 2-3 proxy (uzak veri merkezi/şube’lerden veri toplama). Federe edilmiş topolojide proxy’ler şart.
  • Auto-registration: Yeni Linux/Windows host bir Ansible ile kurulurken Zabbix-agent kurulur ve otomatik kaydolur.
  • Templates: Mono’nun custom template kütüphanesi: web app, DB cluster, K8s node, iş süreçleri.
  • Alarm route’ları: Severity’e göre PagerDuty/Slack/E-mail; rate-limit ile spam kontrolü.
  • Dashboards: Hem Zabbix native hem Grafana (zabbix-datasource plugin) — operatörler kendi dashboard’larını yapsın.

Tipik üretim mimarisi

  1. Zabbix server (HA: 2 node + Pacemaker veya Zabbix HA cluster 6.0+).
  2. TimescaleDB primary + replica.
  3. Zabbix proxy’ler uzak lokasyonlarda (ek + şube + cloud bölge).
  4. Zabbix agent2 (Linux/Windows host’larda); ağ ekipmanı SNMP üzerinden.
  5. Bildirimler: Slack webhook + PagerDuty + e-mail; iş saatleri dışı escalation.

Yaygın sorunlar ve çözümler

  • Yavaş web UI: History/trend tablo boyutu. TimescaleDB sıkıştırması + housekeeper ayarı.
  • Trigger expression yavaş: Kompleks eval ifadeleri. Calculated item’a taşıyın; trigger basit last() > X kalsın.
  • Discovery patlaması: LLD (Low-level discovery) sürekli yeniden eşliyor. Filtre regex’lerini sıkılaştırın.
  • Notification fırtınası: Maintenance, dependency ve trigger expression’da minimum süre filtreleri.
  • Yüksek IOPS: History sync workers + cache config; SSD zorunlu.

İlgili hizmetlerimiz

Sıkça sorulan sorular

Zabbix mi Prometheus mu?
Zabbix ajanlı izleme + agentless SNMP + sentetik test (web monitoring) + native trigger/alarm + envanter yönetimi (CMDB benzeri); uzun dönem metrik tutma native. Prometheus pull-based, K8s/cloud-native, kısa retention + Grafana ile görselleştirme. Mono önerisi: VM/network/iş uygulaması için Zabbix; K8s/uygulama metriği için Prometheus.
Veritabanı için ne kullanmalı?
TimescaleDB (PostgreSQL extension) en iyi seçim — büyük tablolar için partition + sıkıştırma. Eski kurulumlarda MySQL/MariaDB de çalışır; ama 1000+ host’ta kritik bir dezavantaj olur. Mono yeni kurulumlarda zorunlu olarak TimescaleDB öneriyor.
Auto-discovery ne kadar etkili?
Çok etkili: network discovery + active agent auto-registration ile yeni host’lar dakikalar içinde izlemeye girer. Template’ler (Zabbix Template Library) sektöre göre hazır geliyor — Mono ekibi kurumsal standartlar için custom template’ler ekler.
Çok sayıda alarmla nasıl başa çıkılır?
Severity doğru ayarlanmalı; dependency tracking (parent host down ise child alarmları susturulur); maintenance window otomasyonu; trigger expression‘da gürültü filtresi (örn. last() and avg(5m)). Bizim de blog’umuzda yazdığımız üzere SLO temelli alarm tasarımına geçmek olası.

Bir sonraki dönüşümü birlikte planlayalım.

Ekibimiz teknik gereksinimlerinizi anlamak ve hızlıca prototip çıkarmak için hazır.

Bir sonraki dönüşümü birlikte planlayalım.

Ekibimiz teknik gereksinimlerinizi anlamak ve hızlıca prototip çıkarmak için hazır.