Zabbix’i kullanmaya başlamadan önce ilk karar verilmesi gereken konu hangi kurulum yönteminin ihtiyaçlarınıza en uygun olduğudur.

Zabbix farklı ölçeklerdeki sistemler ve kullanım senaryoları için birden fazla kurulum seçeneği sunar. Bu esneklik, hem test ortamlarında hızlı kurulum yapmayı hem de büyük ölçekli üretim ortamlarında kontrollü ve özelleştirilmiş mimariler kurmayı mümkün kılar.

Genel olarak Zabbix’i edinmenin dört temel yolu bulunmaktadır.

a) Dağıtım Paketleri Üzerinden Kurulum (Distribution Packages)

En yaygın ve önerilen yöntemlerden biridir Zabbix’i işletim sisteminin paket yöneticisi aracılığıyla kurmaktır.

Bu yöntemde;

• Zabbix’in resmi repository’si sisteme eklenir,
• Paketler önceden derlenmiş (pre-compiled) olarak gelir,
• Kurulum ve güncelleme süreçleri oldukça kolaydır,

Avantajları

• Hızlı ve stabil kurulum,
• Güncellemelerin kolay yönetilmesi,
• Üretim ortamları için ideal,

Dezavantajları

• Varsayılan yapılandırmalarla gelir,
• Çok ileri seviye özelleştirme gerektiren senaryolarda sınırlı kalabilir,

Best Practice: Production ortamlarında mümkünse her zaman dağıtım paketleri tercih edilmelidir. Bu yöntem bakım ve güncelleme süreçlerinde ciddi operasyonel kolaylık sağlar.

b) Kaynak Koddan Derleyerek Kurulum (Compile from Source)

Zabbix açık kaynak bir yazılım olduğu için kaynak koddan derlenerek de kurulabilir. Bu yöntemde Zabbix’in en güncel veya belirli bir sürümüne ait kaynak kod indirilir ve sistem üzerinde manuel olarak derlenir.

Avantajları

• Tam kontrol ve maksimum özelleştirme,
• İhtiyaç duyulmayan bileşenler kurulmaz,
• Performans optimizasyonu yapılabilir,

Dezavantajları

• Kurulum süresi uzundur,
• Güncellemeler manuel yapılır,
• Deneyimli sistem yöneticileri için uygundur,

Best Practice: Kaynak koddan kurulum genellikle özel ihtiyaçları olan, yüksek performans beklentili veya özel modül entegrasyonu gereken sistemlerde tercih edilmelidir.

c) Container (Docker / Podman) Üzerinden Kurulum

Modern altyapılarda Zabbix container teknolojileri kullanılarak da çalıştırılabilir. Bu yöntemde Zabbix Server, Web arayüzü ve Agent bileşenleri container olarak ayağa kaldırılır.

Avantajları

• Hızlı kurulum,
• Taşınabilirlik,
• CI/CD ve Kubernetes uyumu,

Dezavantajları

• Persistent storage yönetimi dikkat gerektirir,
• Yeni başlayanlar için karmaşık olabilir,

Best Practice: Kubernetes veya mikroservis mimarisi kullanılan ortamlarda Zabbix’in container versiyonları ciddi avantaj sağlar.

d) Sanal Appliance (Virtual Appliance) Kullanımı

Zabbix önceden yapılandırılmış bir sanal makine (virtual appliance) olarak da sunulur. Bu yöntem genellikle demo, eğitim veya hızlı PoC (Proof of Concept) senaryoları için kullanılır.

Avantajları

• Kurulum gerektirmez,
• Hızlıca ayağa kaldırılabilir,

Dezavantajları

• Özelleştirme seçenekleri sınırlıdır,
• Uzun vadeli üretim kullanımı için önerilmez,

Zabbix Kaynak Koduna Erişim

Zabbix’in kaynak koduna erişmek isteyenler için birden fazla seçenek bulunmaktadır. Bu yöntemler genellikle geliştiriciler veya ileri seviye kullanıcılar tarafından tercih edilir.

a) Resmi Web Sitesinden Stabil Sürümler

Zabbix’in stabil (released) sürümleri resmi web sitesinden indirilebilir. Bu sürümler:

• Test edilmiş,
• Uzun süreli destek (LTS) kapsamına alınmış,
• Üretim ortamları için uygundur,

b) Nightly Build’ler

Geliştirme sürecindeki en güncel özellikleri test etmek isteyenler için nightly build sürümleri mevcuttur.

Uyarı: Nightly build’ler kesinlikle üretim ortamlarında kullanılmamalıdır. Bu sürümler hata içerebilir.

c) Git Repository Üzerinden Kaynak Kod Alma

Zabbix’in en güncel geliştirme koduna Git üzerinden erişilebilir.

Ana Git repository adresi:

https://git.zabbix.com/scm/zbx/zabbix.git

Ayrıca GitHub üzerinde de mirror repository bulunmaktadır:

https://github.com/zabbix/zabbix

Git Üzerinden Zabbix Kaynak Kodunu İndirme

Kaynak kodu Git ile almak için sistemde Git client yüklü olmalıdır.

Debian / Ubuntu Üzerinde Git Kurulumu

sudo apt-get update
sudo apt-get install git

Zabbix Kaynak Kodunu Klonlama

git clone https://git.zabbix.com/scm/zbx/zabbix.git

Bu komut Zabbix’in tüm kaynak kodunu belirtilen dizine indirir.

Best Practice: Kaynak kod ile çalışıyorsanız mutlaka branch ve tag yönetimini doğru yapmalı doğrudan master branch üzerinde üretim kurulumu yapmamalısınız.

Gereksinimler ve Kapasite Planlama (Requirements)

Zabbix kurulumunun “sorunsuz açılması” ile “aylarca sorunsuz çalışması” arasında büyük fark vardır. Zabbix’in performansını belirleyen ana unsur çoğu zaman Zabbix server’dan çok veritabanı olur. Bu yüzden gereksinimleri değerlendirirken yalnızca CPU/RAM değil disk, IO, veritabanı ayarları ve veri saklama stratejisi (history/trend/event) birlikte düşünülmelidir.

Aşağıdaki başlıklarda kurulumdan önce mutlaka netleştirmen gereken konuları kapsar.

1) Donanım Gereksinimleri (Hardware)

a) Bellek (Memory) – RAM ve Disk Belleği

Zabbix hem fiziksel bellek (RAM) hem de disk üzerinde depolama tüketir.

Disk alanı neden hızla büyür?

Zabbix’in disk tüketimi temelde şu verilerden oluşur:

• History: ham ölçüm verisi (item değerleri)
• Trends: 1 saatlik özet veriler (min/max/avg/count)
• Events: trigger olayları, recovery kayıtları, event tag’leri
• Ek olarak: indeksler, tablo büyümesi, loglar

Uzun süre history tutmak istiyorsan “birkaç GB” başlangıç için mantıklı görünse bile, orta ölçekten itibaren onlarca/ yüzlerce GB senaryoları çok normaldir.

Best practice (disk):

• Disk boyutundan da önemlisi disk performansı (IOPS / latency).
• Mümkünse SSD/NVMe tercih et.
• Veritabanı için ayrı disk (hatta ayrı sunucu) planlamak, büyüdükçe hayat kurtarır.

RAM neden kritik?

Zabbix server süreçleri, veritabanına çok sayıda bağlantı açar ve DB engine de bellek kullanır.

RAM arttıkça:

• DB cache daha iyi çalışır,
• sorgular hızlanır,
• Zabbix’in genel yanıt süresi iyileşir,

Best practice (RAM):

• Küçük kurulumlarda bile 8–16 GB RAM bandı rahat ettirir.
• Büyük kurulumlarda “Zabbix server hızlı ama DB yavaş” problemi genelde RAM/IO yetersizliğinden çıkar.

b) CPU

Zabbix’in CPU ihtiyacı “host sayısından” çok:

• izlenen metrik sayısına,
• refresh interval (toplama sıklığına),
• preprocessing / dependent item kullanımına,
• DB engine seçimine bağlıdır.

Best practice (CPU):

• Çok kısa interval’lerle (5s/10s) binlerce item toplamak, CPU’yu ve DB’yi hızla zorlar.
• Önce kritik metriklerle başla, sonra ihtiyaç oldukça genişlet.

c) Diğer Donanımlar (SMS vb.)

Zabbix’in SMS bildirim gibi klasik yöntemleri için seri port ve GSM modem gibi ek donanım ihtiyaçları olabilir (USB-to-serial dönüştürücü de iş görebilir).

Ancak günümüzde çoğu kurum:

• email
• webhook (Teams/Slack)
• ITSM entegrasyonları
• SMS gateway servisleri

kullandığı için fiziksel modem senaryosu daha nadir görülür.

Örnek Donanım Boyutlandırma (Başlangıç Ölçekleri)

Zabbix dokümantasyonundaki yaklaşım şunu söyler: “Bunlar sadece başlangıç örnekleri; her kurulum benzersizdir, önce staging ortamında benchmark yap.”

Bunu sahaya çevirecek olursak:

“Monitored metrics” ne demek?

Genelde 1 metrik ≈ 1 item + ona bağlı trigger/graph bileşenleri gibi düşünülür. Ölçek büyüdükçe asıl maliyet DB yazma/okuma tarafına biner.

Tipik başlangıç profilleri (özet)

• Small (~1.000 metrik): 2 vCPU, 8 GB RAM
• Medium (~10.000 metrik): 4 vCPU, 16 GB RAM
• Large (~100.000 metrik): 16 vCPU, 64 GB RAM
• Very large (~1.000.000 metrik): 32 vCPU, 96 GB RAM

Best practice (mimari):

• “Large ve üstü” senaryolarda veritabanını ayrı sunucuya almak şiddetle önerilir.
• Proxy mimarisi (özellikle dağıtık lokasyonlar) hem ölçek hem stabilite için çok değerlidir.

Desteklenen Platformlar (Supported Platforms)

Zabbix bileşenleri farklı işletim sistemlerinde çalışabilir ama üretim tarafında ağırlıkla Linux/Unix tercih edilir. Mantık basittir. monitoring sunucusu “mission-critical” olduğu için performans ve dayanıklılık kritik.

Bileşen bazında genel yaklaşım

• Server: çoğunlukla Linux/Unix üzerinde,
• Agent / Agent 2: Linux ve Windows dahil geniş destek,
• Windows tarafında özellikle Agent 2 için minimum OS ve Go derleyici gereksinimleri daha güncel sürümlere bağlıdır.

Best practice (platform):

• Zabbix Server/DB’yi mümkünse Linux üzerinde konumlandır.
• Windows’larda metrik toplama için agent/agent2 gayet uygundur.

Yazılım Gereksinimleri (Required Software)

Zabbix’in mimarisi üç ana katmana dayanır:

1. Database
2. Zabbix Server/Proxy
3. Frontend (Web UI – PHP + Web server)

a) Veritabanı (DB) Seçimi

Zabbix backend DB olarak MySQL/Percona/MariaDB veya PostgreSQL kullanılabilir.

Büyük yapılarda PostgreSQL ve özellikle TimescaleDB kombinasyonu (zaman serisi verilerde) ciddi avantaj sağlayabilir.

Best practice (DB):

• DB’yi “OS’un default repo paketiyle” kurmak çalışır; ama en iyi deneyim için genelde DB üreticisinin resmi repository’leri tercih edilir.
• InnoDB (MySQL/MariaDB) zorunlu sayılabilir.
• Büyük yapılarda DB tuning şarttır (buffer pool, work_mem, connection limit vs.).

b) Frontend

Frontend tarafında:

• PHP (uyumlu sürüm aralığı)
• Apache veya Nginx
• Gerekli PHP eklentileri (mysqli/pgsql, mbstring, bcmath, sockets, gd, xml, ldap/openssl gibi opsiyoneller)

Best practice (Frontend):

• UI performansı genelde DB performansını yansıtır. UI yavaşsa “web server” değil, çoğu zaman DB sorguları zorlanıyordur.
• Minimum ekran genişliği 1200px gibi pratik gereksinimler bile operasyon tarafında önemlidir (dashboard kullanımı).

c) Server/Proxy ve Agent bağımlılıkları

Server/proxy tarafında libevent, pcre2, curl, snmp, ldap, openssl/gnutls gibi bağımlılıklar; agent tarafında log izleme vb. özellikler için pcre2, curl gibi kütüphaneler devreye girer.

Best practice (feature bazlı):

• SNMP izleyeceksen net-snmp;
• ICMP ping item’ları için fping;
• VMware/HTTP agent item’ları için güçlü libcurl;
• şifreleme kullanacaksan openssl/gnutls tarafı doğru planlanmalı.

Varsayılan Portlar ve Ağ Gereksinimleri

Zabbix iletişimi çoğunlukla TCP üzerinden yürür:

• Agent / Agent2: 10050
• Server / Proxy: 10051
• Java Gateway: 10052
• Web Service: 10053
• Frontend: 80/443

Best practice (network):

• Güvenlik duvarında yalnızca gerekli akışlara izin ver.
• Agent “active” kullanıyorsan, bağlantı yönü değişir (agent server’a çıkar); bu, NAT’lı lokasyonlarda avantaj sağlar.
• “Her yerden 10050 açık” yerine, proxy/active agent tasarımıyla yüzeyi daralt.

Veritabanı Boyutu Nasıl Hesaplanır? (Database Size)

Zabbix’in disk ihtiyacını belirleyen en kritik metrik: values per second (VPS) yani saniyede işlenen değer sayısıdır.

VPS nasıl hesaplanır?

Basit yaklaşım:

• Toplam item sayısı / ortalama refresh interval (saniye)

Örnek:

• 3000 item, refresh 60s → VPS = 3000 / 60 = 50

Bu DB’ye saniyede 50 yeni kayıt eklenmesi demektir.

History saklama süresi büyürse ne olur?

History saklama süresi arttıkça veri katlanır. Numeric item’lar kabaca onlarca bayt ile yüzlerce bayt arası; log/text item’lar çok daha büyüktür.

Trends neden önemli?

Trends 1 saatlik özet veri tuttuğu için uzun süreli raporlama ve grafikte asıl yükü azaltır. Bu yüzden:

• kısa vadede history,
• uzun vadede trends mantığıyla retention tasarlanır.

Events ve tag’ler

Event’ler, recovery kayıtları ve tag’ler de disk tüketir. Çok agresif trigger tasarımı, event sayısını patlatabilir.

Best practice (retention):

• History’yi “her şey için 365 gün” tutmak genelde gereksiz maliyettir.
• Kritik metriklerde daha uzun history, diğerlerinde kısa history + trends yaklaşımı daha sağlıklıdır.
• Log item’ları kontrolsüz açmak yerine, gerektiğinde ve filtreyle kullan.

Zaman Senkronizasyonu (Time Sync)

Monitoring dünyasında zaman hatası domino etkisi yaratır:

• yanlış grafikler
• gecikmeli/erken alarm
• korelasyon problemleri

Best practice:

• Zabbix server, proxy ve izlenen host’larda NTP/chrony ile zaman senkronu zorunlu gibi düşün.
• Dağıtık ortamlarda özellikle proxy saatleri kritik.