Zabbix Performans Optimizasyonu ve Ölçeklendirme

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

Yıllarca Zabbix kurulumu yapıp “şimdi izliyoruz, harika” deyip geçtikten sonra öğreniyorsunuz: asıl iş kurulumdan sonra başlıyor. Ortam büyüdükçe, host sayısı arttıkça, veri saklama süreleri uzadıkça Zabbix’in altında inlemeye başladığını görüyorsunuz. Trigger’lar geç ateşleniyor, grafikler yüklenmiyor, history tablosu kontrol dışı büyüyor. Bu yazıda sıfırdan kurulumu değil, çalışan bir Zabbix ortamını nasıl performanslı hale getirip nasıl ölçeklendireceğinizi konuşacağız.

Sorunun Kökü: Neden Zabbix Yavaşlar?

Genellikle iki temel sebep var. Birincisi veritabanı, ikincisi yanlış yapılandırılmış poller ayarları. Ama iş bununla sınırlı kalmıyor. Şöyle düşünün: 500 host, her birinde 50 item, 5 saniyede bir toplama. Saniyede 5000 değer yazıyorsunuz veritabanına. Bir yıl boyunca bu değerleri tutmaya çalışırsanız history tablosu milyarlarca satıra ulaşıyor. MySQL ya da PostgreSQL bu yükü kaldırmak zorunda kalıyor.

Sorunun tipik belirtileri şunlar:

  • Zabbix Server log dosyasında “zabbix_server busy” uyarıları
  • Slow query log‘da sık görünen history ve trends sorguları
  • Frontend’de grafik yüklenirken timeout
  • Trigger hesaplamalarında 30-60 saniyeye varan gecikmeler
  • zabbix_server -R config_cache_reload komutunun uzun sürmesi

Bunları görüyorsanız doğru yerdesiniz.

Veritabanı Tarafını Düzeltmek

InnoDB Ayarları (MySQL/MariaDB)

Zabbix varsayılan bir MySQL kurulumunu kolayca bunaltır. /etc/mysql/conf.d/zabbix.cnf veya /etc/my.cnf.d/zabbix.cnf dosyasına şunları ekleyin:

[mysqld]
innodb_buffer_pool_size = 8G          # RAM'in %70-80'i
innodb_buffer_pool_instances = 8      # buffer_pool_size / 1GB
innodb_log_file_size = 1G
innodb_log_buffer_size = 256M
innodb_flush_log_at_trx_commit = 2    # Veri kaybı riski az, performans yüksek
innodb_flush_method = O_DIRECT
innodb_read_io_threads = 8
innodb_write_io_threads = 8
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000
max_connections = 300
tmp_table_size = 256M
max_heap_table_size = 256M

innodb_flush_log_at_trx_commit = 2 ayarı hakkında küçük bir not: bu değer 0 veya 2 yapıldığında sistem çökmesinde son 1 saniyelik veri kaybedilebilir. Monitoring verisi için bu genellikle kabul edilebilir. Bankacılık sistemi izlemiyorsunuz, saniyenin transaction verilerini değil.

Partitioning ile History Tablosunu Kontrol Altına Almak

Zabbix’in en ağır tabloları history, history_uint, history_str, history_text, history_log ve trends tablolarıdır. Housekeeping süreci bu tablolardan veri silerken tablo lock’larına neden olabilir. Bunun çözümü partition kullanmak.

Önce mevcut durumu kontrol edin:

mysql -u zabbix -p zabbix -e "
SELECT table_name, 
       ROUND(data_length/1024/1024/1024, 2) AS data_GB,
       ROUND(index_length/1024/1024/1024, 2) AS index_GB,
       table_rows 
FROM information_schema.tables 
WHERE table_schema = 'zabbix' 
ORDER BY data_length DESC LIMIT 10;"

Eğer history_uint tablosu 50GB’ı geçmişse artık partition olmadan hayat zor. Zabbix’in kendi housekeeping’ini devre dışı bırakıp manuel partition yönetimi yapan script’leri devreye alın. Toplulukta yaygın kullanılan partition script’i şöyle çalışır:

# Partition var mı kontrol et
mysql -u zabbix -p zabbix -e "
SELECT partition_name, partition_description 
FROM information_schema.partitions 
WHERE table_name = 'history_uint' 
AND table_schema = 'zabbix' 
ORDER BY partition_description DESC LIMIT 5;"

Partition script’i kurduktan sonra Zabbix frontend’inden Administration > General > Housekeeping sayfasına gidip “Enable internal housekeeping” seçeneklerini kapatın. Artık temizleme işini cron job üzerinden yönetiyorsunuz.

TimescaleDB ile PostgreSQL Üzerinde Çalışmak

Eğer greenfield bir kurulum yapıyorsanız veya taşıma kapasitesine sahipseniz PostgreSQL + TimescaleDB kombinasyonu Zabbix 5.x ve sonrası için çok iyi sonuç veriyor. TimescaleDB, zaman serisi verileri için otomatik partitioning ve compression sağlıyor.

# TimescaleDB extension kurulumu (Ubuntu/Debian)
apt install timescaledb-2-postgresql-14

# postgresql.conf'a ekle
timescaledb.max_background_workers = 8

# Zabbix DB üzerinde
psql -U zabbix zabbix -c "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;"

# Zabbix şema script'ini çalıştır
psql -U zabbix zabbix < /usr/share/doc/zabbix-server-pgsql/timescaledb.sql

TimescaleDB ile history tabloları otomatik olarak hypertable’a dönüşür ve aylık chunk’lar halinde yönetilir. Compression açıldığında disk kullanımını %70-80 oranında düşürdüğünü bizzat gördüm. 2TB olan bir history verisi 400GB’a indi.

Zabbix Server Yapılandırması

/etc/zabbix/zabbix_server.conf dosyası varsayılan değerlerle gelir ve bu değerler küçük ortamlar için bile yetersiz kalabilir.

# Temel process sayıları
StartPollers=80
StartIPMIPollers=5
StartPollersUnreachable=15
StartTrappers=10
StartPingers=10
StartDiscoverers=5
StartHTTPPollers=5
StartTimers=4
StartEscalators=2
StartAlerters=10

# Önbellek ayarları
CacheSize=128M
CacheUpdateFrequency=60
StartDBSyncers=8
HistoryCacheSize=256M
HistoryIndexCacheSize=64M
TrendCacheSize=32M
ValueCacheSize=256M

# Timeout değerleri
Timeout=30
TrapperTimeout=300

# Log ayarları
LogSlowQueries=3000

Bu değerleri körü körüne kopyalamayın. Ortamınıza göre kalibre etmeniz gerekiyor. Bunun için Zabbix’in kendi iç metriklerini izleyin. Zabbix Server host’una Zabbix server health template’ini atayın ve şu metriklere bakın:

  • Utilization of poller processes: Sürekli %80’in üzerindeyse StartPollers artırın
  • Utilization of DB syncers: Yüksekse StartDBSyncers artırın
  • History write cache used: %50’nin üzerindeyse HistoryCacheSize artırın
  • Value cache hits: Düşükse ValueCacheSize artırın
# Anlık process durumunu görmek için
zabbix_server -R diaginfo 2>/dev/null | head -50

Proxy Mimarisi ile Yatay Ölçekleme

Tek bir Zabbix Server ile 10.000 host izlemek mümkün ama akıllıca değil. 2000-3000 host’un üzerinde proxy mimarisine geçmeyi düşünün. Proxy’lerin avantajları:

  • Network segmentasyonu (DMZ, farklı lokasyonlar, müşteri ağları)
  • Server üzerindeki polling yükünün dağıtılması
  • WAN bağlantısı kesildiğinde lokal buffer ile veri kaybının önlenmesi

Proxy kurulumu ve bağlanması:

# Proxy sunucusunda
apt install zabbix-proxy-mysql

# /etc/zabbix/zabbix_proxy.conf
Server=192.168.1.10          # Zabbix Server IP
Hostname=proxy-dc-istanbul
DBHost=localhost
DBName=zabbix_proxy
DBUser=zabbix
DBPassword=secretpass
ProxyMode=0                  # 0=active, 1=passive
ConfigFrequency=3600
DataSenderFrequency=1
StartPollers=40
HistoryCacheSize=128M
ProxyLocalBuffer=1           # Lokal buffer tutma süresi (saat)
ProxyOfflineBuffer=24        # Offline buffer (saat)

Proxy aktif modda çalışıyorsa (ProxyMode=0) server’a bağlanır, konfigürasyonu çeker ve topladığı verileri push eder. Bu firewall açısından avantajlıdır: sadece proxy’den server’a outbound bağlantı yeterli.

Bir gerçek senaryo: İstanbul’da merkez, Ankara ve İzmir’de şube ofisleri olan bir müşteride her şubeye bir proxy koyduk. WAN hattı kesildiğinde lokaldeki cihazlar izlenmeye devam etti, hat geldiğinde biriken veri server’a otomatik olarak gönderildi. Lokal NOC ekibi de kendi şubesinin verilerini proxy üzerinden görebildi.

Frontend Performansı

Web arayüzü yavaşlığının çoğu ya veritabanı sorgularından ya da PHP konfigürasyonundan kaynaklanır.

PHP-FPM Ayarları

# /etc/php/8.1/fpm/pool.d/zabbix.conf
[zabbix]
user = www-data
group = www-data
listen = /run/php/php8.1-fpm-zabbix.sock
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

# PHP memory limiti
php_value[memory_limit] = 256M
php_value[post_max_size] = 16M
php_value[upload_max_filesize] = 2M
php_value[max_execution_time] = 300
php_value[max_input_time] = 300

Nginx Üzerinde Önbellekleme

Static asset’ler için nginx tarafında cache açmak frontend hissini iyileştirir:

# /etc/nginx/conf.d/zabbix.conf içine ekle
location ~* .(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, no-transform";
    access_log off;
}

# Gzip sıkıştırma
gzip on;
gzip_vary on;
gzip_min_length 1000;
gzip_types text/plain text/css application/javascript application/json;

İzleme Stratejisi Optimizasyonu

Performans sorununun bir kısmı teknik değil, mimarisel. Yanlış konfigüre edilmiş item’lar sistemi gereksiz yere yorar.

Polling Aralıklarını Akıllıca Ayarlayın

Her item’ı 30 saniyede bir toplamak gerekmez. Düşük öncelikli metrikleri daha seyrek toplayın:

  • CPU, Memory, Disk I/O: 60 saniye yeterli
  • Network interface traffic: 60 saniye
  • Disk doluluk oranı: 5 dakika (hatta 10 dakika)
  • Log dosyası izleme: 10-30 saniye
  • Servis durumu: 30-60 saniye

Her item’da history storage period ve trend storage period değerlerini de gözden geçirin. Tüm metrikler için 1 yıllık history tutmak zorunda değilsiniz. Debug amaçlı high-frequency item’lar için 7 gün yeterli.

Passive vs Active Agent

Büyük ortamlarda Zabbix Active Agent kullanımı server üzerindeki poller yükünü önemli ölçüde azaltır. Passive agent’ta server agent’a bağlanıp veri çeker. Active agent’ta ise agent’ın kendisi server’a bağlanıp veri gönderir. Bağlantı yönetimi agent tarafına kayar, server sadece dinler.

# /etc/zabbix/zabbix_agentd.conf
# Active agent için
ServerActive=192.168.1.10
Hostname=web-server-01
RefreshActiveChecks=120
BufferSize=1000
MaxLinesPerSecond=100

# Passive'i de bırakabilirsiniz ama büyük ortamda gerekli değil
# Server=192.168.1.10

Template Şişkinliğini Azaltın

“Şablonu aldık, hepsini çektik” sendromu çok yaygın. Bir Linux sunucusu için 200 item mi lazım? Çoğu ortamda hayır. Gereksiz item’ları disabled yapın ya da custom template oluşturun. Özellikle şunlara dikkat edin:

  • Kullanılmayan network interface’lerin discovery’den çıkarılması
  • Mount edilmemiş disk bölümlerinin filtreden geçirilmesi
  • Gereksiz low-level discovery rule’larının kaldırılması

LLD (Low-Level Discovery) filter örneği:

# Filesystem discovery için filter - sadece ext4 ve xfs al
# Filter expression:
{#FSTYPE} MATCHES_REGEX ^(ext4|xfs)$

# Mounted olmayanları çıkar:
{#FSPATH} NOT_MATCHES_REGEX ^(tmpfs|devtmpfs|/run|/sys|/proc)

Monitoring ve Alarm Yorgunluğunu Azaltma

Bu başlık doğrudan performansla ilgili değil ama dolaylı olarak önemli. Aşırı trigger ateşlenmeleri, alarm flapping ve yanlış pozitif uyarılar hem ekibi yoruyor hem de Zabbix’in escalation ve alert mekanizmasını gereksiz yoruyor.

Trigger’larınızda hysteresis ve depends on kullanın:

# Kötü trigger - flapping'e açık
{server01:system.cpu.util.last()}>80

# İyi trigger - 5 dakika üzeri kaldıysa tetikle
{server01:system.cpu.util.min(5m)}>90

# Daha iyi - ortalama ve minimum birlikte
{server01:system.cpu.util.avg(5m)}>85 and {server01:system.cpu.util.min(5m)}>75

Ağ cihazları için “host unavailable” trigger’ına bağımlılık tanımlayın. Switch’e erişim yoksa arkasındaki 20 host’un da alarm üretmesini engelleyin.

Yük Testi ve Kapasite Planlaması

Sisteminizin ne kadar yükü kaldırabileceğini bilmeden ölçeklendirme planı yapamazsınız. Şu sorulara cevap bulun:

# Saniyedeki ortalama değer toplama hızı (NVPS)
mysql -u zabbix -p zabbix -e "
SELECT ROUND(COUNT(*) / 
  (UNIX_TIMESTAMP(NOW()) - MIN(clock)), 2) AS nvps
FROM history_uint 
WHERE clock > UNIX_TIMESTAMP(NOW()) - 3600;"

# Cache hit oranı (Zabbix iç metriklerinden)
# zabbix[vcache,cache,hits] ve zabbix[vcache,cache,misses] item'larına bakın

Genel eşikler:

  • NVPS < 1000: Tek server, varsayılan ayarlar yeterli
  • NVPS 1000-5000: Sunucu ve DB optimizasyonu, SSD zorunlu
  • NVPS 5000-20000: Ayrı DB sunucusu, proxy mimarisi
  • NVPS > 20000: Çoklu proxy, DB clustering veya TimescaleDB şart

Zabbix 6.x ve Sonrası: Yeni Özellikler

Zabbix 6.0 LTS ile gelen bazı özellikler performansı doğrudan etkiliyor:

High Availability (HA) modu: Birden fazla Zabbix Server node’u aktif/pasif olarak çalışabilir. Failover süreleri dakikalar yerine saniyelere indi.

# İkinci node'un zabbix_server.conf'una ekle
HANodeName=zabbix-node-02
NodeAddress=192.168.1.11:10051

Preprocessing worker’ları: Item preprocessing artık ayrı process’lerde çalışıyor. Yoğun preprocessing yapılan ortamlarda StartPreprocessors değerini artırın:

StartPreprocessors=12

Sonuç

Zabbix performans optimizasyonu “bir kez yap, unut” işi değil. Ortamınız büyüdükçe, yeni sistemler eklendikçe tekrar gözden geçirmeniz gerekiyor. Şu adımları bir checklist olarak düşünebilirsiniz:

  • Veritabanı buffer ve I/O ayarlarını sistem kaynaklarına göre kalibre edin
  • History ve trends tablolarını partition veya TimescaleDB ile yönetin
  • Zabbix Server’ın kendi health metriklerini izleyin, darboğazı data ile bulun
  • 2000+ host’tan itibaren proxy mimarisini değerlendirin
  • Active agent’a geçin, poller yükünü azaltın
  • Template şişkinliğini temizleyin, polling aralıklarını akıllıca ayarlayın
  • Trigger kalitesini artırın, alarm yorgunluğunu azaltın

En sık yapılan hata şu: sorun çıktıktan sonra çözmeye çalışmak. Zabbix’i izlerken aynı zamanda Zabbix’i izlemeniz gerekiyor. Kendi sunucunuzu da izleme kapsamına alın, kapasite eşiklerini önceden belirleyin. Sistem yöneticiliğinde sürpriz sevmeyiz.

Bir yanıt yazın

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