Zabbix ve Nagios: Sunucu İzleme, Kurulum ve Alarm Yönetimi (2026)

Zabbix ve Nagios: Sunucu İzleme, Kurulum ve Alarm Yönetimi (2026)

Sunucu odanızda gece yarısı bir disk doluyor, MySQL connection pool çöküyor veya bir web servisi 502 dönmeye başlıyor — siz farkına bile varmadan müşteriler durumu Twitter'dan bildiriyor. Modern sysadmin'in en çok kaçındığı senaryo budur. Bunu önleyen tek pratik araç: gerçek zamanlı, eşik tabanlı, otomatik alarm üreten bir izleme (monitoring) altyapısı.

Bu rehberde sunucu izlemenin iki klasik OSS aracı Zabbix ve Nagios'u derinlemesine ele alıyoruz: mimari, kurulum, alarm yönetimi, ölçek, modern alternatiflerle karşılaştırma ve Buyukweb VDS perspektifinden self-host kurulum stratejisi. Yazı sysadmin'in pratik karar verme tonuyla yazılmıştır — versiyon-spesifik notlar ve gerçek dünya operasyonel kaygıları (alarm yorgunluğu, MTTR, eskalasyon) ön plandadır.

Neden Self-Host İzleme?

SaaS izleme servisleri (3. parti dashboard hizmetleri) anında kuruluyor olabilir; ancak Türkiye'de iş yapan bir altyapıda self-host (kendi sunucunuzda barındırılan) izlemenin somut avantajları vardır:

• Veri kontrolü ve KVKK uyumu: Sunucu metrikleri, log içerikleri, hata mesajları zaman zaman kişisel veri içerebilir. Bu verinin yurt dışındaki bir SaaS'a aktarılması KVKK kapsamında değerlendirilmesi gereken bir transferdir; self-host bu sorunu kökten çözer.
• Sabit maliyet: SaaS izleme genellikle host/metric başına ücretlendirir; 50-100 sunucu üzerinde aylık maliyet hızla şişer. Buyukweb VDS üzerinde Zabbix server tek sabit ücrettir; host eklemek ücretsizdir.
• Alarm otonomu: Self-host alarm zinciri yurt dışı bir servise bağımlı değildir. SaaS provider'ın çökmesi sizi kör bırakır; kendi Zabbix server'ınız çalışmaya devam eder.
• Türkçe içerik ve topluluk: Zabbix özellikle Türkçe yerelleştirme ve doküman açısından zengin; Türk sysadmin topluluğunda yaygın.
• Özelleştirme: SaaS plan limitleri (sorgu sayısı, retention, custom metric) sizi bağlar; OSS Zabbix/Nagios ile şablonu, eşiği, retention'ı tam serbest yapılandırırsınız.

Karşı argüman olarak self-host'un operasyonel maliyetini de dürüst yazmak gerekir: Zabbix server güncelleme, DB bakım, disk kapasitesi planlama ve high availability (HA) tasarımı sizin sorumluluğunuzdadır.

İzleme Felsefesi: Black Box vs White Box

İzleme literatürü iki ana yaklaşım tanımlar; ikisi de aynı altyapıda paralel kurulur.

Black box monitoring (dışarıdan izleme): Sunucuya bakmadan, dış bir noktadan "site açılıyor mu, response time ne, HTTP 200 dönüyor mu" sorusunu yanıtlar. Uptime check, ICMP ping, TCP port check, HTTP GET. Müşterinin gördüğü dünyayı izler.

White box monitoring (içeriden izleme): Sunucunun içine kurulan agent (ajan) ile CPU, RAM, disk I/O, network throughput, MySQL slow query, Apache request rate gibi iç metrikleri toplar. Sorun çıkmadan önce uyarır.

Sağlıklı bir izleme katmanı her ikisini birden kurar: black box "siteyi erişilebilirlik açısından" güvence altına alır, white box "neden yavaşladı, neden çökecek" sorusunu yanıtlar.

Bunun yanında modern observability üç ana sinyal türünü ayırır:

• Metrik (metric): Sayısal zaman serisi — CPU %, RPS, latency. Zabbix ve Nagios primarily bu alanda güçlüdür.
• Log: Yapılandırılmış veya serbest metin olay kayıtları — Apache access.log, application error log. Loki, Elastic veya Graylog gibi araçlar bu alana hizmet eder.
• Trace: Dağıtık sistemlerde tek bir isteğin servisler arasında dolaşımı — distributed tracing. Jaeger veya OpenTelemetry ekosistemine girer.

Bu rehber primarily metrik tarafına odaklıdır; Zabbix ve Nagios bu üçlünün en köklü ve olgun temsilcileridir.

Zabbix Derinlemesine

Zabbix, Letonyalı Alexei Vladishev tarafından 2001'de geliştirilen, GPLv2 lisanslı tam açık kaynaklı bir izleme platformudur. 2026 itibarıyla Zabbix 7.0 LTS üretim için yaygın tercih, Zabbix 7.2 ise stable rolling release olarak güncellemeleri taşır.

Zabbix Mimarisi

Tipik bir Zabbix kurulumu dört bileşenden oluşur:

• Zabbix Server: Alarm değerlendirme, veri saklama (DB'ye yazma), eylem (action) tetikleme. Sunucunun beynidir.
• Zabbix Agent: İzlenecek her sunucuya kurulan ajan; sistem metriklerini toplar ve server'a aktarır.
• Zabbix Frontend: PHP tabanlı web arayüzü; Apache veya Nginx üzerinde çalışır.
• Zabbix Database: MySQL/MariaDB, PostgreSQL veya TimescaleDB. Tüm metrik ve konfigürasyon burada saklanır.

Ölçek büyüdüğünde Zabbix Proxy devreye girer: uzak lokasyondaki agent'lardan veri toplar, ana server'a buffer'lı şekilde aktarır. Coğrafi olarak dağıtık altyapılar (örneğin Bursa veri merkezi + İstanbul müşteri lokasyonu) veya 1000+ host izlemede proxy node mimarisi şarttır.

Zabbix Agent vs Agent2

Zabbix 4.4 ile gelen Zabbix Agent 2 (Go ile yazılmış), klasik C ile yazılan Zabbix Agent'in modern halefidir.

Özellik	Zabbix Agent	Zabbix Agent 2
Dil	C	Go
Plugin sistemi	Yok	Var (built-in plugin)
Container desteği	Sınırlı	Native (Docker, podman)
Eşzamanlı kontrol	Tek thread	Çoklu goroutine
MQTT/Modbus/PostgreSQL plugin	Yok	Built-in
Bellek tüketimi	Daha düşük	Biraz daha yüksek

Yeni kurulumlar için Agent 2 önerilir; özellikle PostgreSQL, MongoDB, Docker gibi servisleri izlerken built-in plugin'leri ek konfigürasyon olmadan kullanırsınız.

Auto-Discovery ve LLD

Zabbix'in büyük gücü auto-discovery (otomatik keşfetme) mekanizmasıdır:

• Network discovery: Belirli bir IP aralığını tarar, yanıt veren host'ları otomatik server listesine ekler.
• Active agent auto-registration: Yeni kurulan bir agent server'a kendini tanıtır; şablon otomatik atanır.
• Low-Level Discovery (LLD): Bir host'un içindeki dinamik öğeleri keşfeder — mount edilmiş tüm diskler, ağ arayüzleri, MySQL veritabanları, çalışan servisler. Her keşfedilen öğe için ayrı ayrı izleme item'ı otomatik yaratılır.

LLD pratik faydası: yeni bir disk takıldığında veya yeni MySQL veritabanı oluşturulduğunda, manuel müdahale olmaksızın izleme başlar.

Trigger, Macro ve Dashboard

Trigger: Bir koşulun true olduğu anda alarm üreten ifade. Zabbix trigger expression dili güçlüdür:

{server01:system.cpu.util[,user].avg(5m)}>85

"server01 host'unda kullanıcı CPU kullanımı son 5 dakikalık ortalamada %85'i geçerse" anlamına gelir.

Macro: Şablon ve trigger içinde değişken kullanma — `{$CPU_THRESHOLD}` gibi. Host bazında özelleştirilebilir; production sunucular için %85, dev sunucular için %95 eşiği gibi.

Dashboard: Web UI üzerinde sürükle-bırak ile grafik widget'ları konumlandırma; aynı host'un CPU, RAM, disk grafiklerini tek sayfada görmek.

Problem ve Event: Trigger'ın çalıştığı an bir event üretir; event'ler bir araya gelerek problem'i oluşturur. Problem ack edilebilir, üzerine yorum eklenebilir, severity düzeyi değiştirilebilir — basit alarmdan ekibin ortak müdahale yönetimine geçiş yapar.

Web Monitoring ve API

Zabbix sadece sistem metriği değil, dış HTTP servislerini de izler:

• Web scenario: Bir web sayfasının açılma süresi, dönen HTTP kodu, sayfa içeriğinde belirli bir string'in varlığı.
• Synthetic check: Login formundan başlayan çok adımlı bir senaryoyu otomatik koşturma, her adımın yanıt süresini metric olarak kaydetme.

Zabbix REST API: Tüm UI işlemleri JSON-RPC API üzerinden de yapılabilir; CI/CD pipeline'ından otomatik host ekleme, şablon güncelleme, alarm bastırma mümkün.

Nagios Derinlemesine

Nagios, 1999'da Ethan Galstad tarafından "NetSaint" adıyla başlatılan, daha sonra 2002'de Nagios olarak yeniden adlandırılan, izleme dünyasının en köklü açık kaynaklı projesidir. İki büyük dağıtım vardır:

• Nagios Core: GPL lisanslı, tam açık kaynak. Bu yazının odağı.
• Nagios XI: Nagios Core üzerine ticari özellikler eklenen ücretli sürüm. Modern UI, gelişmiş raporlama, capacity planning dahil.

Nagios'un mimari yaklaşımı Zabbix'ten farklıdır — plugin tabanlı, dosya-konfigürasyonlu bir sistemdir.

Nagios Mimarisi

• Nagios Core process: Tanımlı kontrolleri (check) zamanlanmış aralıklarla çalıştırır, sonuçlarına göre durum (state) belirler.
• Nagios Plugins: Asıl kontrol işini yapan harici scriptler/binary'ler. `check_ping`, `check_http`, `check_disk`, `check_mysql` vb. her plugin tek bir kontrolü yapar ve standart çıktı + exit code döner.
• Konfigürasyon: `.cfg` flat-file biçimi. Host, service, contact, command tanımları metin dosyalarında durur. Geleneksel ama Zabbix'in DB-temelli yaklaşımından zahmetli.

Active vs Passive Check

Active check: Nagios server bir komutu kendi çalıştırır (örneğin `check_ping`) ve sonucu okur.

Passive check: Uzaktaki sistem sonucu Nagios'a kendiliğinden gönderir. NSCA (Nagios Service Check Acceptor) bu senaryoda kullanılır.

NRPE (Nagios Remote Plugin Executor): Uzak host üzerinde plugin çalıştırmak için. Tipik kurulum:

[Nagios Server] --(NRPE TCP 5666)--> [Uzak Host: nrpe daemon] --(local plugin)--> sonuç

Notification ve Escalation

Nagios'un alarm modeli daha basittir ama disiplinli: contact, contactgroup, notification_period, escalation tanımlanır.

# escalation örneği
define serviceescalation {
    host_name           web01
    service_description HTTP
    first_notification  3
    last_notification   5
    notification_interval 10
    contact_groups      sysadmin-manager
}

İlk 2 bildirim sıradan oncall'a gider; 3-5 arasındaki bildirimler manager grubuna eskalate olur.

Nagios 2026 Perspektifi

Açık konuşmak gerekirse Nagios Core, 2020'lerin ortasında klasik bir araç haline gelmiş durumda. cfg dosyalarıyla uğraşmak, web UI'ın modernlikten uzak olması, container/dynamic infrastructure entegrasyonunun zahmetli olması — yeni kurulumlarda sysadmin'ler genellikle aşağıdaki seçeneklere yöneliyor:

• Zabbix: Modern UI, DB-temelli config, auto-discovery built-in.
• Icinga 2: Nagios kodundan 2009'da çatallanmış (fork), modern DSL config, REST API, dağıtık mimari. Nagios'un "modernleştirilmiş hali" olarak düşünülebilir.
• Checkmk Raw Edition: Almanya merkezli, Nagios üzerine kurulmuş ama kendi web UI'ı ve agent'ıyla gelir. Raw Edition GPL lisanslı.

Yine de mevcut Nagios kurulumunuz varsa migrate etmek pahalı bir karardır; bu yazıda Nagios'u "history + güçlü yanları + sınırlamaları" perspektifinden ele alıyoruz.

Zabbix vs Nagios: Karşılaştırma Matrisi

Kriter	Zabbix 7.x	Nagios Core 4.x
Konfigürasyon	DB + web UI	.cfg dosyaları
Web UI modernliği	Yüksek	Klasik
Auto-discovery	Native + LLD	Plugin (zahmetli)
Distributed monitoring	Proxy mimarisi native	NRPE/NSCA ile elde edilir
REST API	Tam JSON-RPC	Sınırlı (Nagios XI'de güçlü)
Şablon (template) sistemi	Zengin, miras (inheritance)	Plugin + commands
Alarm severity	Information/Warning/Average/High/Disaster	OK/Warning/Critical/Unknown
Bildirim kanalı	Email, Slack, Telegram, webhook, SMS gateway	Email, SMS, webhook (script ile)
Container/Docker	Agent 2 ile native plugin	Eksik (3. parti gerekir)
Veritabanı	MySQL, PostgreSQL, TimescaleDB	NDOUtils ile MySQL (opsiyonel)
Öğrenme eğrisi	Orta	Yüksek (cfg + plugin)
Türkçe topluluk	Geniş	Sınırlı
Plugin ekosistemi	Şablon kütüphanesi + community	Çok geniş (Nagios Exchange)
Lisans	GPL v2	GPL v2 (Core); XI ticari

Pratik karar matrisi:

• Sıfırdan kurulum, modern UI, kolay öğrenme → Zabbix
• Mevcut Nagios cfg yatırımı, eski plugin tabanı → Nagios kalmaya devam edebilir, ya da Icinga 2'ye geçiş
• Kubernetes / container-native ortam → Prometheus + Grafana
• Görsel real-time dashboard önceliği → Netdata (hafif kurulum)

Zabbix 7.0 LTS Kurulumu (Ubuntu 22.04)

Buyukweb VDS root yetkili bir Ubuntu 22.04 ortamında kurulum adımları:

1. Repository Ekle

wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.0+ubuntu22.04_all.deb
dpkg -i zabbix-release_latest_7.0+ubuntu22.04_all.deb
apt update

2. Server, Frontend, Agent Kurulumu

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

MySQL/MariaDB kullanıyorsanız ilk komut bu şekildedir; PostgreSQL için `zabbix-server-pgsql` paketi alırsınız.

3. Veritabanı Hazırlığı

mysql -uroot -p <<'SQL'
CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'StrongPasswordHere';
GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost';
SET GLOBAL log_bin_trust_function_creators = 1;
SQL

Schema'yı import edin:

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

Import sonrası `log_bin_trust_function_creators` ayarını geri çevirin:

mysql -uroot -p -e "SET GLOBAL log_bin_trust_function_creators = 0;"

4. Zabbix Server Konfigürasyonu

`/etc/zabbix/zabbix_server.conf` dosyasında DB parolasını ayarlayın:

DBPassword=StrongPasswordHere

5. PHP Frontend Saat Dilimi

`/etc/zabbix/apache.conf` içinde:

php_value date.timezone Europe/Istanbul

6. Servisleri Başlat

systemctl restart zabbix-server zabbix-agent2 apache2
systemctl enable zabbix-server zabbix-agent2 apache2

7. Web UI ve İlk Kurulum

`http://SUNUCU_IP/zabbix\` adresine gidin; setup wizard üzerinden DB bağlantısı, server adı, default time zone seçimi yapın. Varsayılan kullanıcı: `Admin` / parola `zabbix` — ilk girişte mutlaka değiştirin.

8. Agent'ı İzlenecek Sunucuya Kurma

Diğer her sunucuda:

wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.0+ubuntu22.04_all.deb
dpkg -i zabbix-release_latest_7.0+ubuntu22.04_all.deb
apt update
apt install -y zabbix-agent2

`/etc/zabbix/zabbix_agent2.conf` içinde:

Server=ZABBIX_SERVER_IP
ServerActive=ZABBIX_SERVER_IP
Hostname=web01.example.com

Servisi başlatın: `systemctl enable --now zabbix-agent2`. Web UI'da Configuration > Hosts üzerinden yeni host'u manuel ekleyin veya auto-registration kullanın.

Alarm Yönetimi: Trigger'dan Eskalasyona

Bir alarm sisteminin gerçek değeri "doğru zamanda doğru kişiye doğru mesajı iletmek" yeteneğindedir. Alarm yorgunluğu (alert fatigue) gerçek bir tehlikedir: ekibi sürekli false positive ile bombardımana tutarsanız, gerçek kritik alarm geldiğinde ekibin sessizleşmiş bir Slack kanalında bulur.

Trigger Eşikleri ve Severity

Zabbix severity seviyeleri:

Severity	Kullanım	Bildirim Hedefi
Information	Bilgi notu (yeni host eklendi, yedek aldı)	Loglanır, bildirim gitmez
Warning	Sorun yaklaşıyor (CPU %75)	Slack/email
Average	Sorun var ama kritik değil (CPU %85)	Slack + email
High	Hizmet etkilenmek üzere (CPU %95)	SMS + Slack
Disaster	Hizmet çöktü, müşteri etkileniyor	SMS + telefon araması

Trigger Dependency

Bir router çöktüğünde ardındaki 20 sunucu hep birden "unreachable" görünür ve 20 ayrı alarm üretilirse ekip boğulur. Zabbix trigger dependency bu sorunu çözer: router trigger'ı aktif olduğunda, bağımlı host trigger'ları otomatik bastırılır.

Time Period (Bakım Penceresi)

Planlı bakım sırasında alarm üretilmesini istemezsiniz. Zabbix maintenance period mekanizması belirli host/grup için belirli zaman aralıklarında alarm bildirimini kapatır.

Eskalasyon (Escalation)

Zabbix actions içinde escalation step'leri tanımlanır:

Action: Disaster severity uyarısı
Step 1 (0. dakika):   Slack #ops kanalı + email oncall
Step 2 (5. dakika):   Email + SMS oncall mühendis
Step 3 (15. dakika):  SMS + telefon araması — operasyon yöneticisi
Step 4 (30. dakika):  SMS — CTO

Eğer problem 5. dakikada ack edilir ve çözülür ise, sonraki step'ler tetiklenmez.

Bildirim Kanalları

Zabbix `Media types` üzerinden çeşitli kanallar:

• Email: SMTP relay; en yaygın kanal.
• Slack: Incoming webhook URL; kanal başına yönlendirme.
• Discord: Webhook ile entegrasyon (sysadmin Discord sunucuları yaygın).
• Telegram bot: BotFather ile bot oluşturma, chat_id alma, webhook ile mesaj gönderme.
• SMS gateway: Yerli Türkçe SMS provider (Twilio reseller veya yerli operatör API) ile entegre webhook.
• Custom script: `zabbix_sender` ile her senaryo özelleştirilebilir.

Alarm Yorgunluğunu Azaltma Pratikleri

Sahada işe yarayan kurallar:

• Threshold'ı baseline'a göre belirleyin — CPU %50 kritik mi yoksa normal mi? Sunucunun 30 günlük ortalamasına bakın.
• Hysteresis ekleyin — CPU %85'i geçtiğinde alarm üret, %75'in altına düştüğünde "OK" gönder. Eşik etrafında flapping önlenir.
• Süre koşulu kullanın — "5 dakikalık ortalama %85 üstü" demek "anlık sıçramaları" eler.
• Kategorize edin — production / staging / dev. Dev ortam alarmları farklı kanala düşsün.
• Sessiz saatleri tanımlayın — bakım pencereleri ile dev ortamlarının gece alarmlarını kısın.
• MTTR ölçün — her alarm için "tespitten çözüme süre" kaydı tutun; tekrarlayan alarm tipleri için otomasyon (self-healing) yatırımı yapın.

Genişletilebilirlik: Custom Plugin ve Item

Hazır şablonlar her senaryoyu karşılamaz. Hem Zabbix hem Nagios kendi metriğinizi eklemenizi kolaylaştırır.

Zabbix UserParameter

`/etc/zabbix/zabbix_agent2.d/custom.conf` dosyasına:

UserParameter=mysql.slow_queries,mysql -uroot -p'PASS' -BNe "SHOW GLOBAL STATUS LIKE 'Slow_queries'" | awk '{print \$2}'

Agent yeniden başlatıldıktan sonra Zabbix server'dan `mysql.slow_queries` key'ini istediğinizde komut çıktısı metric olarak döner.

Zabbix Sender

Tek seferlik veya cron job ile metric göndermek için:

zabbix_sender -z ZABBIX_SERVER_IP -s "web01" -k custom.deploy.count -o 1

CI/CD pipeline'da her deploy sonrası bu komut çalıştırılırsa, Zabbix dashboard'da deploy sayacı grafiklenir.

Nagios Custom Plugin

Nagios plugin'leri exit code ve standart çıktı sözleşmesine uyar:

Exit Code	Anlam
0	OK
1	WARNING
2	CRITICAL
3	UNKNOWN

Örnek plugin (`/usr/local/nagios/plugins/check_mysql_conn.sh`):

#!/bin/bash
COUNT=\$(mysql -uroot -p'PASS' -BNe "SHOW STATUS LIKE 'Threads_connected'" | awk '{print \$2}')
WARN=80
CRIT=150

if [ "\$COUNT" -ge "\$CRIT" ]; then
    echo "CRITICAL - MySQL connections: \$COUNT | conn=\$COUNT;\$WARN;\$CRIT;;"
    exit 2
elif [ "\$COUNT" -ge "\$WARN" ]; then
    echo "WARNING - MySQL connections: \$COUNT | conn=\$COUNT;\$WARN;\$CRIT;;"
    exit 1
else
    echo "OK - MySQL connections: \$COUNT | conn=\$COUNT;\$WARN;\$CRIT;;"
    exit 0
fi

`|` sonrası gelen `conn=$COUNT;$WARN;$CRIT;;` ifadesi perfdata formatıdır; PNP4Nagios veya Graphite gibi grafik araçlarınca okunur.

Pratik Dashboard Senaryoları

İzleme altyapısının somut faydası dashboard tasarımıyla ortaya çıkar. Tipik kullanım senaryoları:

Web Sunucu (Apache/Nginx)

Anahtar metrikler:

• HTTP request rate (RPS)
• Response code dağılımı (2xx, 3xx, 4xx, 5xx) — 5xx artışı kritik
• Average response time (latency)
• Active connections
• Worker process / thread pool kullanımı

Apache için `mod_status` modülü açılır; Zabbix Apache template'i bu endpoint'ten otomatik veri çeker. Nginx için `stub_status` modülü benzer rolü oynar.

MySQL / PostgreSQL

• Active connection count vs max_connections
• Slow query rate (saniyede slow query)
• InnoDB buffer pool hit ratio
• Replication lag (master/slave senaryosu)
• Disk I/O (data dir disk)

PostgreSQL için `pg_stat_activity`, `pg_stat_replication` view'ları temel veri kaynağıdır.

Linux Sistem

• CPU kullanımı (user / system / iowait ayrı ayrı)
• RAM (used / cached / buffers / swap)
• Disk doluluk (her mount point ayrı)
• Disk I/O latency
• Network throughput (in/out)
• Load average (1m / 5m / 15m)

`iowait` yüksek ise CPU değil disk darboğazı; `load average` CPU sayısının 2-3 katını geçtiyse process kuyruğu oluşmuş.

SSL Sertifika Expiry

Zabbix `net.tcp.tls.cert.validity` item'ı ile sertifika kalan ömrü metric olarak izlenir; 30 gün altında uyarı, 7 gün altında kritik kuralı kurun.

Mail Server (Postfix/Exim)

• Mail queue uzunluğu (`mailq | wc -l`)
• Saniye başına gönderilen mail
• Bounce rate
• SMTP auth fail rate

Mail queue 1000 üstüne çıkarsa server stuck olmuş demektir; alarm kritik severity ile düşmelidir.

Buyukweb VDS Perspektifi

Buyukweb VDS sunucu paketleri tam root yetkili Linux ortamı sunar; Zabbix server kurulumu için ideal seçenektir. cPanel paylaşımlı hosting üzerinde Zabbix veya Nagios server kurulması mümkün değildir — paylaşımlı hosting ortamında root yetkisi yoktur, port açma ve systemd servis kurma yasaktır.

Önerilen VDS Paketi Tablosu

Senaryo	Önerilen Paket	RAM	Disk	Açıklama
1-20 host izleme	E5 v2 VDS — Başlangıç	4 GB	60 GB SSD	Tek server + agent + DB
20-100 host	E5 v2 VDS Pro	8 GB	100 GB SSD	DB ayrı, daha fazla retention
100-500 host	E5 v4 VDS	16 GB	200 GB NVMe	Yoğun yazma, hızlı sorgu
500+ host, distributed	Fiziksel Dedicated + proxy node	32 GB+	500 GB+ NVMe	Proxy mimarisi, replikasyon

NVMe SSD özellikle önemlidir; Zabbix history table sürekli yazma altındadır. Spinning disk yüksek host sayısında disk I/O darboğazı oluşturur.

Agent Tarafı

Buyukweb VDS sunucularında Zabbix agent2 kurulumu serbesttir. Buyukweb cPanel paylaşımlı hosting üzerinde agent kurmak pratikte mümkün değildir (root erişim yok, daemon kurma yasak); paylaşımlı hosting'te HTTP-level uptime check (black box) ile sınırlı kalırsınız.

Network ve Bütçe

50 host'lu Zabbix kurulumunda agent→server trafiği aylık 3-5 GB civarındadır. Buyukweb VDS paketlerinin trafik kotası bunun çok üstündedir; trafik faturası endişesi yoktur.

Teknik destek için 0850 302 60 70 numarasını arayabilir veya iletişim sayfamıza yazabilirsiniz.

Güvenlik Pratikleri

İzleme altyapısı kendisi de saldırı yüzeyidir — bir saldırgan Zabbix server'ı ele geçirirse 100 host'unuzun tüm metriklerini, hatta agent üzerinde uzaktan komut çalıştırma yetkisini elde edebilir.

Frontend HTTPS

Zabbix web UI'ı mutlaka HTTPS arkasına alın; Let's Encrypt + Nginx reverse proxy ile sertifika ücretsiz. HTTP üzerinden web UI'a giriş yapmak parola sızıntısı demektir.

AllowKey / DenyKey Kısıtlaması

Zabbix agent konfigürasyonunda `AllowKey` ile sadece izin verilen key'ler çalıştırılır. `system.run[]` gibi uzaktan komut çalıştırma key'i varsayılan kapalı olmalıdır; gerçekten gerekli değilse açmayın.

AllowKey=system.cpu.*
AllowKey=vm.memory.*
DenyKey=system.run[*]

Agent PSK Encryption

Zabbix agent ↔ server arası iletişim TLS PSK (pre-shared key) ile şifrelenebilir. Production kurulumlarda mutlaka açılmalıdır; veri "ortada" gezerken ele geçirilemez.

TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=PSK_001
TLSPSKFile=/etc/zabbix/zabbix_agent2.psk

Firewall Kısıtlaması

• 10050/tcp — agent → server (passive check)
• 10051/tcp — server → agent (active check, sender)

Bu portlar sadece Zabbix server IP'sinden erişilebilir olmalıdır; public internete açılmamalıdır.

ufw allow from ZABBIX_SERVER_IP to any port 10050
ufw allow from ZABBIX_SERVER_IP to any port 10051

DB ve Yedek

Zabbix DB'yi düzenli yedekleyin; tüm trigger ve şablon konfigürasyonu burada. `mysqldump` veya `pg_dump` cron'la günlük; en az 7 günlük yedek tutun.

Karşılaştırma: Modern Alternatifler

Bu yazının odağı Zabbix ve Nagios olsa da, 2026 monitoring ekosistemini gerçekçi göstermek için kısa bir bakış:

Prometheus (pull tabanlı, sunucudan metric çeker; Kubernetes ekosisteminde fiili standart; PromQL sorgu dili güçlü; Grafana ile birlikte kullanım). Container-native ortam için ideal.

Netdata (real-time görsel, kurulum 1 satır, agent UI built-in). Tek sunucu görselleştirmesi için en hızlısı; merkezi alarm yönetimi için tek başına yetersiz.

Checkmk Raw Edition (Nagios üzerine kurulmuş ama kendi UI'ı ve agent'ıyla gelir, GPL). Almanya kökenli, kurumsal kullanım yaygın.

Icinga 2 (Nagios fork, modern DSL config, REST API, dağıtık mimari). Nagios cfg'lerinden çıkış arayanlara uygun.

Sensu Go (event tabanlı modern izleme, Go ile yazılmış). Cloud-native için tasarlanmış; OSS sürümü daha küçük topluluğa sahip.

Centreon (Nagios fork, Fransa kökenli, modern UI, business service management). Avrupa'da yaygın.

Sıkça Sorulan Sorular

Zabbix mi Prometheus mu seçmeliyim?

Sunucu/ağ donanımı, SNMP cihazları, geleneksel altyapı izlemesi → Zabbix kazanır (SNMP, IPMI, ICMP built-in destek; auto-discovery güçlü; agent push modeli geleneksel sysadmin işine uygun). Kubernetes, Docker, microservice uygulama metrikleri → Prometheus kazanır (pull model + service discovery container ortamlarına uygun; PromQL sorgu dili modern uygulama metriği için tasarlanmış). Pratikte birçok kurum ikisini birden çalıştırır: Zabbix altyapı tarafı, Prometheus container tarafı; iki dashboard Grafana üzerinden birleştirilir.

Hangi senaryoya hangi araç?

Senaryo	İlk Tercih	Alternatif
1-10 sunucu hızlı kurulum	Netdata	Zabbix
10-200 sunucu, geleneksel altyapı	Zabbix	Icinga 2
Kubernetes / container	Prometheus + Grafana	—
Tek sunucu görsel + alarm	Netdata + Uptime Robot (dış)	—
Mevcut Nagios mevcut, eklemek istemiyoruz	Nagios koru, Icinga 2'ye taşıma roadmap	Checkmk Raw
Network device (router/switch) izleme	Zabbix (SNMP güçlü)	LibreNMS

Zabbix agent paylaşımlı hosting'te kurulabilir mi?

Pratikte hayır. Paylaşımlı hosting (cPanel/Plesk) ortamında root yetkisi olmaz, daemon kurulamaz, port açılamaz. Maksimum yapabileceğiniz HTTP-level black box check (dışarıdan uptime monitor). Tam metric izleme için VDS veya dedicated sunucu gerekir.

Zabbix DB'sini MySQL mi PostgreSQL mi seçmeliyim?

İki seçenek de production-ready. MySQL/MariaDB geleneksel Zabbix kurulumlarında daha yaygındır; sysadmin ekibinizin MySQL bilgisi varsa kullanımı kolaydır. PostgreSQL büyük ölçek (500+ host, yoğun history) için biraz daha iyi yazma performansı sunar; TimescaleDB extension ile birlikte kullanıldığında zaman serisi sorgu performansı ciddi artar. Yeni kurulumlar için TimescaleDB + PostgreSQL kombinasyonu ileri ölçeklenebilirlik açısından öneri olarak öne çıkar; mevcut MySQL DBA bilginiz varsa MySQL ile başlamak pratik.

Alarm yorgunluğunu nasıl yönetirim?

Üç katmanlı yaklaşım: (1) Eşikleri baseline'a göre belirleyin — sunucunun normal CPU ortalaması %40 ise %60'a alarm koyma; (2) Hysteresis + süre koşulu kullanın — anlık sıçramalara alarm vermeyin; (3) Severity matrisi tanımlayın — Warning Slack'e, Disaster SMS'e. Ekibin "her alarmı ciddiye al" güveni korunmalı. Her ay alarm sayısı/kişi metriğine bakın; haftada 50'den fazla alarm alan biri tükenir.

Sonuç

Zabbix ve Nagios, açık kaynaklı sunucu izleme dünyasının iki köklü temsilcisidir. Zabbix modern UI, DB-temelli config, auto-discovery, dağıtık proxy mimarisi ve zengin şablon ekosistemi ile yeni kurulumlar için pratik tercih olarak öne çıkıyor. Nagios ise plugin ekosisteminin genişliği ve onlarca yıllık operasyonel olgunluğu ile mevcut kurulumlarda yerini koruyor; ancak yeni projeler için sysadmin'ler genellikle Zabbix, Icinga 2 veya Checkmk Raw'a yöneliyor.

Self-host izleme altyapısı KVKK uyumu, sabit maliyet, alarm otonomu ve özelleştirilebilirlik açısından Türkiye'de iş yapan operasyonlar için belirleyici avantajlar sunar. Buyukweb VDS'in tam root yetkili Ubuntu ortamı bu altyapıyı kurmak için ideal — paylaşımlı hosting'in aksine port açma, daemon kurma, sistem servisi yapılandırma serbestliği vardır.

Alarm sisteminin asıl değerinin "alarm sayısı" değil, "doğru zamanda doğru kişiye giden, harekete geçirilebilir alarm" olduğunu unutmayın. Threshold belirleme, hysteresis, severity, eskalasyon ve bakım pencereleri — bunlar sysadmin disiplinin parçasıdır ve aracın kendisinden bağımsız olarak doğru kurulmalıdır.

Teknik sorularınız için 0850 302 60 70 numarasını arayabilir veya iletişim sayfamıza yazabilirsiniz.

---

İlgili Büyükweb Hizmetleri

Zabbix veya Nagios self-host kurulumu için root yetkili sunucu seçenekleri:

• VDS Sunucu — Tam root, KVM sanallaştırma, küçük-orta izleme altyapısı için
• E5 v4 VDS — NVMe SSD, yoğun history yazma altında ideal
• Paket Karşılaştırma — Tüm VDS paketlerini karşılaştırın
• Fiziksel Dedicated Sunucu — 500+ host, distributed proxy mimarisi için

Sorularınız için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz.