Ağ İzleme ve Bandwidth Analizi: Zabbix, Nagios, SNMP ve NetFlow

Ağ izleme neden gerekli, bandwidth nasıl ölçülür? iftop/nethogs/nload/vnstat Linux araçları, SNMP v1/v2c/v3, NetFlow/sFlow/IPFIX, Zabbix 7.0 LTS vs Nagios karşılaştırma, Prometheus/Grafana alternatifi ve Buyukweb VDS üzerinde tek sunucu kurulum rehberi.

Büyükweb Editör EkibiHosting, Sunucu ve Sistem Yönetimi Editörü18 Eylül 202527 dakika okumaGüncellendi · 11 Mayıs 2026

Ağ İzleme ve Bandwidth Analizi: Zabbix, Nagios, SNMP ve NetFlow

Bir sistem yöneticisinin gecesini kabusa çeviren cümle: "Site çok yavaş, müşteri arıyor." O an iki ihtimal vardır: ya bir problemi daha ortaya çıkmadan görmüş ve önlemini almıştır, ya da reaktif olarak arıza ortasına dalar. Ağ izleme (network monitoring) ve bandwidth analizi, bu iki yaklaşımı birbirinden ayıran en önemli teknik disiplindir. Bu rehber tek bir araç anlatımı değil; bir IT yöneticisi veya sistem yöneticisinin kavramsal temel + Linux native araçlar + SNMP/NetFlow + tam ölçek Zabbix kurulum + Nagios karşılaştırma + Prometheus alternatifi + kapasite planlama olmak üzere uçtan uca öğrenmesi gereken her şeyi tek dosyada sunuyor.

Buyukweb perspektifi: Bursa Tier 3 veri merkezimizdeki VDS E5-V4 sunucularımız, KVM sanallaştırma ile tam root erişim sağlar. Aylık ₺250-600 arası seviyeden başlayan bu sunucularda kendi Zabbix 7.0 LTS veya Nagios Core platformunuzu kurabilir, çoklu host'u tek noktadan izleyebilirsiniz. Standart DDoS L3+L4+L7 koruması, %99.8 uptime ve günlük yedekleme (Veeam altyapısı) ile izleme platformunuz da güvende olur. Detay ve uygun paket için 0850 302 60 70 veya [email protected].

Ağ İzleme Neden Gerekli? Reaktif vs Proaktif Yaklaşım

İzleme yapmayan bir sistem yöneticisi sadece şikayet eden müşterilerden problem öğrenir. Ölçüm yoksa optimizasyon yoktur; optimizasyon yoksa rekabet avantajı yoktur. İki yaklaşımı karşılaştıralım:

Boyut	Reaktif (İzleme Yok)	Proaktif (İzleme Var)
Problem tespit kaynağı	Müşteri şikayeti, telefon, Twitter	Otomatik alarm, dashboard
Tipik MTTD (Mean Time To Detect)	30 dakika - 4 saat	30 saniye - 5 dakika
Tipik MTTR (Mean Time To Resolve)	Saatler	Dakikalar
Kapasite planlama	Sezgisel, tahmin	Trend grafiği, kapasite eğrisi
Müşteri algısı	"Bunlar problem çıkardıktan sonra anlıyor"	"Bunlar problemi ben farketmeden çözüyor"
Maliyet yönetimi	Aşırı/eksik kaynak yatırımı	Optimum noktada kaynak
SLA uyum izleme	Mümkün değil	Yıllık SLA raporu çıkarılır
Olay sonrası post-mortem	"Ne oldu hatırlamıyoruz"	Tam zaman çizelgesi mevcut
Bilgi paylaşımı	Sadece o kişinin kafasında	Ekip ortak dashboard'tan görür
Yönetici karar verme	Hissi, sezgisel	Veri tabanlı

Sonuç açık: izleme, profesyonel bir IT operasyonunun olmazsa olmaz birinci adımıdır. "Şu an çalışıyor, zaten bakmak gerekmez" tutumu, ilk büyük outage'a kadar tutar; sonrasında ya bütçe ya da iş bilenler değişir.

Üç Tip İzleme: Availability, Performance, Capacity

Pratikte üç farklı izleme amacı vardır ve birbirine karıştırmamak gerekir:

Availability monitoring (erişilebilirlik): "Çalışıyor mu, çalışmıyor mu?" — TCP/HTTP probe, ICMP ping, port kontrolü. En basit izleme.
Performance monitoring (performans): "Ne kadar hızlı çalışıyor?" — yanıt süresi, throughput, CPU/RAM/disk/network metrikleri, uygulama içi APM (uygulama performans izleme).
Capacity monitoring (kapasite): "Ne zaman doluyor?" — 30/60/90 günlük trend grafiği, kapasite eğrisi, büyüme oranı. Önceden satın alma kararı için gerekir.

Profesyonel bir izleme stack'i bu üç boyutu da kapsar. Sadece "ping atıyor mu" demek yetmez; ping atıyor ama TTFB 8 saniyeyse müşteri yine de yakılır.

Bandwidth Kavramı: bps mi Bps mi? Baseline ve Capacity Planning

Network bandwidth ölçümünde kafa karışıklığı yaratan en temel mesele birim sistemidir. bps (bit per second) ile Bps (byte per second) arasında 8x fark vardır ve fatura/SLA dökümanlarında doğru birimi okumamak şirketleri sürekli yanıltır.

bps vs Bps — 8x Çarpı

1 Byte (B) = 8 bits (b)
1 Mbps = 1.000.000 bps (megabit per second) — taşıyıcı seviyesi
1 MBps = 1.000.000 Bps (megabyte per second) — dosya transfer hızı

Örnek: "100 Mbps internet" hattı maksimum 12.5 MB/s dosya indirme yapabilir
(100 / 8 = 12.5)

Sektör konvansiyonu:

bps / Mbps / Gbps → ISP, switch port, network kart, taşıyıcı kapasite
Bps / KB/s / MB/s → dosya transfer hızı, kullanıcı yüzü, indirme/yükleme
IOPS → disk I/O ölçümü (ağ değil, ayrıştırmak gerekir)

Bir VDS satın alırken "100 Mbps port" denildiğinde aslında pratik dosya transfer hızı 12 MB/s seviyesindedir (TCP/IP overhead dahil edilirse ~10-11 MB/s gerçek).

Baseline (Temel Çizgi) Çıkarma

İzlemeye yeni başlayan bir ortamda ilk hedef mevcut durum baseline'ını ölçmek olmalıdır:

2-4 haftalık veri toplama — ortalama, p50, p90, p99 yüzdelikler
Saat dilimi farkındalığı — sabah 09-11, öğle 12-14, akşam 18-23 farklı pattern
Gün/hafta sonu farkı — pazartesi sabahı != cumartesi gecesi
Sezonsal etki — pazarlama kampanyası, kara cuma, ramazan, yılbaşı

Baseline çıktıktan sonra anomaly detection (anormal sapma tespiti) mümkün olur. Mesela baseline'da p99 = 200 Mbps ise ve birden 800 Mbps görülüyorsa, ya bir saldırı ya da yeni bir uygulama var — alarm çıkar.

Capacity Planning (Kapasite Eğrisi)

30/60/90 günlük büyüme trendi çıkarılır:

Ay 1 ortalama:  250 Mbps
Ay 2 ortalama:  290 Mbps  → %16 büyüme
Ay 3 ortalama:  330 Mbps  → %14 büyüme
Doğrusal projection: 6. ay sonu ~600 Mbps

Hedef: 1 Gbps port doluluk %80'e ulaşmadan port upgrade satın al
Doluluk oranı %80'e ulaşma tahmini: ~10. ay sonu
Aksiyon: 7. ay sonunda yeni port satın alımı başlat

Kapasite eğrisi olmadan kararlar reaktif olur: port doldu, müşteri etkilendi, sonra aceleyle hat yenilenir. Eğri varsa planlı upgrade mümkündür.

Linux Native Bandwidth Araçları (CLI)

VDS veya bare metal sunucu üzerinde bir SSH oturumu ile saniye seviyesinde ne olduğunu öğrenmek için Linux'ta zengin CLI araç ekosistemi vardır. Her aracın güçlü tarafı farklıdır.

iftop — Bağlantı Bazlı Canlı Trafik

# Kurulum
sudo apt install iftop       # Debian/Ubuntu
sudo dnf install iftop       # Rocky/AlmaLinux/RHEL

# Çalıştırma (eth0 interface'i)
sudo iftop -i eth0

# Port numarası göster, DNS çözme kapat (daha hızlı)
sudo iftop -i eth0 -P -n

Ne zaman kullanılır? Hangi IP ile ne kadar trafik var, anlık görmek için. "Sunucu yavaş, kim çekiyor?" sorusunun en hızlı cevabı.

nethogs — Process Bazlı Trafik

sudo apt install nethogs
sudo nethogs eth0

iftop'tan farkı: trafik bağlantı yerine process (PID) bazlı gösterilir. "Hangi PHP-FPM worker'ı bu kadar veri çekiyor?" gibi sorular için biçilmiş kaftan.

nload — Throughput Görselleştirme

sudo apt install nload
nload eth0

Gelen/giden trafiği ASCII grafik olarak gösterir. Hızlı bir kanıt görüntüsü için sezgisel. Tarihsel veri tutmaz, anlık görünüm.

bmon — Multi-Interface Monitor

sudo apt install bmon
bmon

Birden fazla network interface'i (eth0, eth1, bond0, tun0, vmbr0...) aynı ekranda görmek için. Veri merkezi sysadmin'in tercihi.

vnstat — Tarihsel Bandwidth İstatistikleri

sudo apt install vnstat
sudo systemctl enable --now vnstat

# Saatlik, günlük, aylık özet
vnstat -h
vnstat -d
vnstat -m

# 5 dakikalık canlı izleme
vnstat -l -i eth0

vnstat kalıcı (persistent) veritabanı tutar. Sunucu yeniden başlatılsa bile aylık trafik raporu kaybolmaz. Aylık trafik kotası takibi için altyapı sağlar.

iptraf-ng — Detaylı Network İstatistik

sudo apt install iptraf-ng
sudo iptraf-ng

ncurses tabanlı interaktif menü: TCP/UDP istatistikleri, LAN trafiği, protokol dağılımı, ARP cache. Modern alternatif var ama hala canlı eğitim/ders senaryolarında popüler.

Hangi Araç Ne Zaman?

İhtiyaç	Araç
Anlık bağlantı bazlı trafik	iftop
Process bazlı trafik	nethogs
Throughput görsel (ASCII grafik)	nload
Birden fazla interface tek ekran	bmon
Tarihsel günlük/aylık trafik	vnstat
Detaylı TCP/UDP protokol istatistik	iptraf-ng
Tek seferlik trafik snapshot	sar -n DEV

Pratik öneri: Her VDS sunucumuza minimum vnstat yüklemenizi öneririz. Aylık trafik kotası takibi için en hafif ve güvenilir araçtır. Sorun çıktığında üzerine iftop veya nethogs çalıştırırsınız.

Paket Analizi: ss, ip, tcpdump, tshark

Bandwidth seviyesinden bir kademe daha derine inerek bağlantı seviyesi ve paket seviyesi analiz gerekir. Bu, gerçek bir hata teşhisinin başladığı yerdir.

ss — Socket Statistics (netstat'ın halefi)

# Açık TCP bağlantılar
ss -tn

# Listen eden portlar + process bilgisi
sudo ss -tlnp

# Belirli porta gelen bağlantılar
ss -tn 'sport = :443'

# Connection state özet
ss -s

netstat modası geçmiş; modern dağıtımlarda ss standart araç. Daha hızlı, daha detaylı, kernel'in netlink soketinden direk veri çeker.

ip — Route ve Interface

# Network interface durumu
ip a

# Routing tablo
ip route

# ARP komşu tablosu
ip neighbor

# Belirli interface istatistik
ip -s link show eth0

ifconfig ve route deprecated; ip komutu tüm modern Linux dağıtımlarında standart.

tcpdump — Komut Satırı Paket Sniffer

# eth0 üzerinde HTTP trafiği yakala
sudo tcpdump -i eth0 -nn port 80

# Belirli host ile trafiği yakala
sudo tcpdump -i eth0 -nn host 198.51.100.42

# Dosyaya kaydet (Wireshark'ta açılır)
sudo tcpdump -i eth0 -w /tmp/capture.pcap -c 1000

# Yakalanmış dosyayı oku
sudo tcpdump -r /tmp/capture.pcap -nn -X

tcpdump pcap (packet capture) formatında dosya üretir. Bu dosya Wireshark veya tshark ile sonradan offline analiz edilebilir.

tshark — Wireshark'ın CLI Versiyonu

# eth0 üzerinde TLS handshake'leri filtrele
sudo tshark -i eth0 -Y "tls.handshake.type == 1"

# DNS sorgu/cevaplarını yakala
sudo tshark -i eth0 -Y "dns" -T fields -e dns.qry.name

# pcap dosyasını protocol istatistiği olarak özetle
tshark -r /tmp/capture.pcap -q -z io,stat,1

tcpdump'tan farkı: dissector (protokol çözücü) çok daha güçlü. HTTP, TLS, DNS, SMB, MQTT, MySQL protokol seviyesinde paket çözer. SSH üzerinden tshark çalıştırıp lokalde Wireshark'a stream etmek de mümkündür.

Güvenlik notu: tcpdump çalıştırırken parolalar ve hassas veriler plain text olarak görülebilir (TLS olmayan trafik için). Production ortamında kısıtlı süre + minimum filtreleme ile çalıştırın, dosyayı saklamayın, iş bitince silin.

SNMP: Standart Sunucu/Cihaz İzleme Protokolü

Sunucular, switch'ler, router'lar, yazıcılar, UPS'ler, firewall'lar — fiziksel ve sanal her cihaz SNMP (Simple Network Management Protocol) üzerinden izlenebilir. SNMP 1988 yılından beri var ve hala IT dünyasının izleme protokolü omurgasıdır.

SNMP Versiyonları

Versiyon	Yayın	Güvenlik	Kullanım
SNMPv1	1988	Yok (community string clear text)	Eski cihaz, legacy
SNMPv2c	1993	Yok (community string clear text)	Hala yaygın (varsayılan)
SNMPv3	2002	USM (User-Based Security Model) — auth + privacy	Modern, önerilen

SNMPv1 / v2c community string adlı şifresiz bir paroladır. Aynı LAN segmentinde clear text yayıldığı için public network'te güvensizdir. Yine de iç ağda yaygın kullanılır çünkü kurulumu kolay.

SNMPv3 USM ile authentication (MD5/SHA) ve privacy (DES/AES) sağlar. Modern bir izleme stack'inde SNMPv3 zorunlu kabul edilmelidir.

SNMP Mimarisi

[Manager / NMS]               [Agent (Sunucu/Cihaz)]
 Zabbix Server,         ←UDP 161 GET/GETNEXT/GETBULK→        snmpd, switch IOS
 Nagios, LibreNMS                                              firmware
                        ←UDP 162 TRAP/INFORM─

MIB (Management Information Base) — OID (Object Identifier) ağaç yapısı:
 .1.3.6.1.2.1.1.5.0  → sysName
 .1.3.6.1.2.1.1.3.0  → sysUpTime
 .1.3.6.1.2.1.2.2.1.10.X → ifInOctets (X = interface index)

Linux Üzerinde snmpd Kurulum (SNMPv3)

# Ubuntu/Debian
sudo apt install snmp snmpd snmp-mibs-downloader

# /etc/snmp/snmpd.conf — SNMPv3 user
sudo systemctl stop snmpd

# Önce bir USM user oluştur (auth = SHA, privacy = AES)
sudo net-snmp-create-v3-user -ro -A AuthParolasi -X PrivParolasi -a SHA -x AES izleme_user

# Servisi başlat
sudo systemctl start snmpd
sudo systemctl enable snmpd

# Test (başka makineden)
snmpwalk -v3 -u izleme_user -l authPriv -a SHA -A AuthParolasi -x AES -X PrivParolasi <SUNUCU_IP> system

SNMP Ne Sağlar?

System info: hostname, uptime, OS version, contact, location
Network interface: trafik (in/out octet sayacı), paket sayısı, hata sayısı, MTU
CPU/RAM: kullanım yüzdesi, load average
Disk: doluluk yüzdesi, IOPS (Net-SNMP UCD-DISKIO-MIB ile)
Process: belirli process aktif mi (apache2, mysqld vb.)
Custom: kendi script'inizi UCD-SNMP-MIB::extOutput ile expose edebilirsiniz

SNMP'nin Sınırları

Pull tabanlı — agent push edemez (TRAP hariç, ama TRAP queue/retransmit zayıf)
State tutmaz — sadece anlık değer veya counter
Detaylı uygulama metriği zayıf — HTTP yanıt süresi, SQL sorgu hızı vb. için yeterli değil
Modern alternatif: agent-based push modeli (Zabbix Agent, Telegraf, Prometheus exporter)

NetFlow, sFlow, IPFIX: Flow Tabanlı Trafik Analizi

Bandwidth grafiği "100 Mbps trafik var" der ama kim ile kim arasında, hangi protokol, hangi port bilgisi vermez. Bunun için flow tabanlı izleme gerekir. Switch/router flow record üretir, bir collector toplar, bir analiz aracı görselleştirir.

NetFlow (Cisco)

Cisco tarafından 1996 yılında geliştirildi, en yaygın flow protokolüdür. Versiyon 5 klasik (sabit alanlar), versiyon 9 ve sonrası template tabanlı (esnek alan).

Bir flow şu beşli ile tanımlanır (5-tuple):

Source IP
Destination IP
Source Port
Destination Port
Protocol (TCP/UDP/ICMP)

Buna byte sayısı, paket sayısı, başlangıç/bitiş zamanı, interface index, TCP flag gibi alanlar eklenir.

sFlow (Sampled Flow)

Donanım üreticileri (HP, Brocade, Juniper) tarafından desteklenen alternatif. Örnekleme tabanlı — her N pakette bir örnek alır, CPU yükü çok düşük. Ölçek anlamında çok büyük networklerde NetFlow'a tercih edilir.

IPFIX (Internet Protocol Flow Information Export)

IETF standardı (RFC 7011). NetFlow v9'un standartlaştırılmış hali. Geleceğin formatı olarak değerlendirilir, çoğu modern cihaz IPFIX'i export edebilir.

Açık Kaynak NetFlow Collector

nfdump / nfsen — klasik, hafif, CLI + basit web UI
pmacct (Cisco/Juniper destekli, çok formatlı)
Akvorado (modern, ClickHouse + Kafka tabanlı)
GoFlow2 (Cloudflare tarafından geliştirildi, açık kaynak)
ntopng (community + pro versiyonlar, görsel olarak güçlü)

Pratik Senaryo: Router'dan Buyukweb VDS'e NetFlow Export

1. Router'da NetFlow v9 export ayarla, hedef: VDS public IP, UDP 2055
2. VDS'te nfcapd çalıştır:
   nfcapd -w -D -l /var/cache/nfcapd -p 2055
3. Toplanan flow'ları analiz et:
   nfdump -r /var/cache/nfcapd/nfcapd.YYYYMMDDHHMM -A srcip,dstip,bytes
4. nfsen web UI üzerinden trend grafiği görüntüle

Veri merkezi seviyesinde flow analizi, DDoS tespiti, anormal trafik tespiti ve fatura/billing için kritiktir.

MRTG ve RRDTool: Tarihsel İzleme Altyapısı

İzleme tarihinin bir bölümünü öğrenmek bugünkü kararları daha sağlam kılar. MRTG (Multi Router Traffic Grapher) 1995'te yazılan, SNMP ile router/switch trafiğini ölçen ve PNG grafik üreten bir araçtı. Sıkıştırılmış log formatı (sabit boyut, eski veriler agreged) ile tasarlandı.

RRDTool (Round Robin Database), MRTG'nin yazarı tarafından geliştirilen modern veri saklama motorudur. Bugün hala Cacti, collectd, Zenoss, observium, Munin gibi araçların altyapısında RRD vardır.

RRD özellikleri:

Sabit boyutlu veritabanı — disk dolması yok
Round-robin — eski veriler average/min/max olarak konsolide edilir
Hızlı grafik üretimi — built-in graph engine
Time-series için ideal

Modern alternatifler (InfluxDB, Prometheus TSDB, VictoriaMetrics, TimescaleDB) RRD'den daha esnek ama temel kavram aynıdır.

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

Açık kaynak izleme dünyasının iki klasik ismi: Zabbix ve Nagios. Hangisi sizin için doğru? Karar matrisi:

Özellik	Zabbix 7.0 LTS	Nagios Core 4
Yayın yılı	2001	1999
Yapılandırma	Web UI + DB tabanlı	Dosya tabanlı (cfg)
Discovery	Otomatik, agent-side LLD	Eklenti gerekir
Agent	Zabbix Agent (1 ve 2)	NRPE / NSCA
Veritabanı	MySQL/PostgreSQL/TimescaleDB	Dosya tabanlı, opsiyonel DB
Web UI	Modern, dashboard, host map	Basit (Core), Plus ücretli
Trigger / alarm dili	Expression based, çoklu boyut	Plugin return code
Template kütüphanesi	Geniş resmi + topluluk	Eklenti tabanlı
Notification	Email, SMS, webhook, IM, custom script	Email, SMS, webhook (eklenti)
Ölçek	100K+ host (proxy ile)	Daha küçük (eklenti gerekir)
Topluluk	Aktif, sertifikasyon	Aktif, eski ekol
LTS sürüm	5 yıl destek	Sürekli (community)
API	REST + JSON-RPC tam	CGI tabanlı, sınırlı
Mobile app	Resmi var	Resmi yok, üçüncü parti
Distributed monitoring	Zabbix Proxy yerleşik	Eklenti
Auto-remediation	Action + script	Eventhandler scripts
Anomaly detection	Built-in trend prediction	Eklenti gerekir

Karar:

Yeni başlayan, modern stack, ölçekli izleme: Zabbix
Klasik UNIX felsefesi, basit dosya tabanlı, mevcut ekosistem: Nagios
Aşırı esnek metric + alert + dashboard, modern cloud-native: Prometheus + Grafana (aşağıda)

Zabbix 7.0 LTS Sunucu Kurulumu (Ubuntu 22.04)

Buyukweb VDS üzerinde tek sunucu Zabbix kurulumu için adım adım rehber. Bu kurulum monitör sunucu rolündedir; izleyeceğiniz host'lara ayrı Zabbix Agent yüklemeniz gerekir.

Ön Gereksinimler

Ubuntu 22.04 LTS VDS (2 vCPU, 4 GB RAM minimum; 8 GB öneri)
Public IP, root SSH erişim
Aktif domain (opsiyonel, web UI için)
Aylık ~₺250-350 seviyesinde Buyukweb VDS E5-V4 yeterli

Adım 1: Sistem Güncelleme

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl wget gnupg2 software-properties-common

Adım 2: Zabbix Resmi Repo Ekle

# Zabbix 7.0 LTS repo (Ubuntu 22.04 için)
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest+ubuntu22.04_all.deb
sudo dpkg -i zabbix-release_latest+ubuntu22.04_all.deb
sudo apt update

Adım 3: MySQL/MariaDB Kur

sudo apt install -y mariadb-server mariadb-client
sudo mysql_secure_installation

# Zabbix DB hazırla
sudo mysql -u root -p

CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'ZABBIX_DB_PAROLA_GUCLU';
GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost';
SET GLOBAL log_bin_trust_function_creators = 1;
FLUSH PRIVILEGES;
EXIT;

Adım 4: Zabbix Server + Frontend + Agent Kur

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

# Şema ve initial data import
zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql --default-character-set=utf8mb4 -uzabbix -p zabbix

# Sonradan tekrar açma
sudo mysql -u root -p -e "SET GLOBAL log_bin_trust_function_creators = 0;"

Adım 5: Zabbix Server Konfigürasyon

sudo nano /etc/zabbix/zabbix_server.conf

# Aşağıdaki satırları bul, düzenle (yorum işaretini kaldır)
DBHost=localhost
DBName=zabbix
DBUser=zabbix
DBPassword=ZABBIX_DB_PAROLA_GUCLU
CacheSize=128M           # Host sayısı arttıkça artır
StartPollers=10
StartTrappers=5

Adım 6: PHP Timezone Ayarla

sudo nano /etc/zabbix/apache.conf

# php_value date.timezone satırını bul ve TR olarak ayarla
# php_value date.timezone Europe/Istanbul

Adım 7: Servisleri Başlat

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

# Log kontrol
sudo tail -f /var/log/zabbix/zabbix_server.log

Adım 8: Web UI Setup

Tarayıcıdan açın: http://VDS_IP/zabbix

Setup wizard:

Welcome → Next step
Check of pre-requisites — tüm satırlar OK olmalı
Configure DB connection — Database name: zabbix, User: zabbix, Password: ZABBIX_DB_PAROLA_GUCLU
Server details — Host: localhost, Port: 10051, Name: izleme.sirket.com
GUI settings — timezone: Europe/Istanbul, default theme: Blue (veya Dark)
Summary → Next → Finish

İlk giriş: Admin / zabbix (hemen değiştirin!)

Adım 9: TLS/HTTPS — Let's Encrypt

sudo apt install -y certbot python3-certbot-apache
sudo certbot --apache -d izleme.sirket.com -m [email protected] --agree-tos --redirect

certbot otomatik renewal cron'u eklenir; sertifika 3 ayda bir yenilenir.

Adım 10: Firewall

sudo ufw allow 22/tcp        # SSH
sudo ufw allow 80,443/tcp    # Web UI
sudo ufw allow 10051/tcp     # Zabbix Server (agent'lar bağlanır)
# Agent'tan server'a değil; server agent'a port 10050 bağlanır
sudo ufw enable

Buyukweb VDS notu: Veri merkezimizdeki standart DDoS L3+L4+L7 koruması Zabbix server'ınızı saldırılara karşı kalkanlar. Ek olarak günlük yedekleme ile veritabanınız kaybolma riskine karşı korunur.

Zabbix Template, Item, Trigger, Action Kavramları

Zabbix mimarisini kavramak için Template → Host → Item → Trigger → Action zincirini anlamak gerekir.

Template

Belirli bir cihaz/uygulama türü için Item + Trigger + Discovery rule + Graph koleksiyonudur. "Linux server", "MySQL DB", "Apache web server", "Switch SNMP" gibi hazır şablonlar Zabbix kurulumuyla gelir. Hosta uygulanır.

Host

İzlenen birim — fiziksel sunucu, VM, VDS, container, switch, vb. Bir host'a bir veya daha fazla template eklenir.

Item

Tek bir ölçüm noktası. Örnekler:

system.cpu.load[,avg1] — 1 dakikalık CPU load
vfs.fs.size[/,pfree] — / partition boş yüzde
net.if.in[eth0] — eth0 in-bound trafik (byte/sn)
vfs.dev.read.ops[sda] — sda read IOPS
agent.ping — agent yaşıyor mu

Trigger

Item'lar üzerinde expression ile alarm tanımı:

{Linux:vfs.fs.size[/,pfree].last()}<10
→ "Disk doluluk %90 üzeri" — High severity

{Linux:net.if.in[eth0].avg(5m)}>100000000
→ "Network trafiği 100 Mbps üzeri 5 dakikadır" — Warning

Action

Trigger ateşlendiğinde ne yapılacağı:

E-posta gönder ([email protected])
SMS gönder (sysadmin telefon)
Webhook (Slack, Teams, Telegram bot)
Custom script (otomatik servis restart)
Eskalasyon (10 dk sonra çözülmediyse mesaj genişlet)

Low-Level Discovery (LLD)

Otomatik discovery. Örnek: bir Linux host'ta LLD ile tüm disk partition'lar keşfedilir, her biri için ayrı item + trigger açılır. Manuel eklemeye gerek yok.

Prometheus + Grafana: Modern Alternatif

Modern cloud-native dünyada Prometheus + Grafana stack'i Zabbix/Nagios'a alternatif olarak değerlendirilmelidir.

Prometheus

Pull tabanlı — Prometheus kendisi agent'lara/exporter'lara bağlanır ve metric çeker
Time-series DB — kendi yerleşik TSDB
PromQL — sorgu dili
Service discovery — Kubernetes, Consul, DNS SRV, static config
Federation — birden fazla Prometheus birbirinden veri çekebilir

Grafana

Görselleştirme — Prometheus, InfluxDB, MySQL, PostgreSQL, Elasticsearch ve onlarca veri kaynağına bağlanır
Dashboard — paylaşılabilir, JSON import/export
Alert — alert rule + notification kanalları

Pull vs Push Modeli

Boyut	Pull (Prometheus)	Push (InfluxDB Telegraf, Zabbix sender)
Network mimari	Server agent'a ulaşır	Agent server'a push eder
Firewall karmaşıklığı	Server inbound delik gerek (agent → server)	Agent outbound (server'a)
Discovery	Service discovery güçlü	Manuel veya event tabanlı
Short-lived process	Zayıf (kısa süreli job kaçabilir)	İyi (push edip biter)
NAT/firewall ardı	Zor (proxy gerekir)	Kolay
Operasyonel basitlik	Kurulduktan sonra basit	Daha esnek

Hangi Stack?

Bulut-native, Kubernetes ağırlıklı, çok metric → Prometheus + Grafana
Klasik sunucu/VDS, ağ cihazları, SNMP ağırlıklı, hazır template → Zabbix
Sade availability + basit dashboard → Uptime Kuma (aşağıda)
Klasik Unix, dosya tabanlı config, sade alarm → Nagios

İki dünyayı birleştirmek de mümkün: Zabbix item'ları Grafana dashboard'una pipe edilebilir; Zabbix datasource plugin Grafana'da hazır gelir.

Uptime Kuma: Sade Self-Host Alternatif

Tüm bu sistemler ağır gelir, sadece "site açık mı, ping atıyor mu, sertifika ne zaman bitiyor" izlemek istiyorum diyorsanız Uptime Kuma mükemmel bir seçimdir.

# Docker ile tek komut
docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1

Özellikler:

Monitor types: HTTP(s), TCP, ICMP ping, DNS, push, Steam, Docker
Notification: Discord, Slack, Telegram, e-posta, webhook, 90+ kanal
Status page: müşterilere açık public status sayfası
Certificate expiry alarm: SSL bitmeden 7/14/30 gün uyarı
2FA, multi-user desteği

Buyukweb VDS üzerinde ₺250/ay seviyesinde tek sunucuda Uptime Kuma çalıştırarak 100+ web sitesi/servisin availability'sini izleyebilirsiniz. Web UI sade, kurulum 5 dakika.

Alarm Fatigue: SLO, SLI, RED Method

Çok fazla alarm = hiç alarm. Bir sistem yöneticisi sabah 100 e-posta alıyorsa hiçbirini ciddiye almaz. Alarm fatigue profesyonel izleme yapan ekiplerin en büyük tuzağıdır.

SLI (Service Level Indicator)

İzlemek istediğin metric. Örnek:

HTTP 200 yanıt oranı (success rate)
p99 yanıt süresi
Sipariş tamamlanma oranı

SLO (Service Level Objective)

Hedefin. Örnek:

HTTP 200 oranı >= %99.9 (rolling 30 gün)
p99 yanıt süresi <= 400 ms
Sipariş tamamlanma oranı >= %99.5

SLA (Service Level Agreement)

Müşteriye verilen söz, SLO'nun bir alt seviyesidir. SLO ihlali iç alarm; SLA ihlali fatura iadesi seviyesidir.

Error Budget

SLO %99.9 ise %0.1 hata bütçeniz var. 30 gün = 43.200 dakika; %0.1 = 43.2 dakika izinli arıza. Bu bütçeyi yedek/güncelleme/deploy/feature rollout için kullanırsınız. Bütçe bitti mi → "freeze, yeni feature yok, sadece stabilizasyon" kararı alınır.

RED Method (Web/API için)

Tom Wilkie'nin önerdiği üç temel ölçüm:

Rate — saniyede istek sayısı
Error — saniyede hatalı istek sayısı (5xx)
Duration — yanıt süresi dağılımı (p50, p90, p99)

Bir API endpoint için bu üç ölçüm yeterli olur. Aşırı detay yerine az ama doğru metric.

USE Method (Resource için)

Brendan Gregg'in önerdiği üç temel ölçüm:

Utilization — kaynak kullanım yüzdesi
Saturation — kuyruk uzunluğu, beklemede kalan istek
Errors — hata sayısı

Bir CPU, disk, network kartı için USE method yeterli.

Sonuç: Yüzlerce alarm yerine SLO ihlali → bildirim modeli uygulayın. Müşteri etkilenecek hata varsa alarm, etkilenmiyorsa dashboard'da say. Alarm SMS/telefonla geliyorsa gerçekten gece uyandırılmaya değer mi sorusunu test edin.

Capacity Planning: 30 Gün Baseline → Trend → Kapasite Eğrisi

Bir VDS veya bare metal sunucu üzerinde kapasite planlama üç adımdan oluşur:

Adım 1: Baseline (30 gün)

Network: in/out bps, p50/p90/p99
CPU: kullanım yüzdesi, load avg
RAM: kullanım GB, swap aktivite
Disk: doluluk yüzdesi, IOPS okuma/yazma
Uygulama: istek/sn, yanıt süresi p99

Adım 2: Trend (60-90 gün ileri)

Doğrusal/üstel regresyon:

y = a + b*x      (doğrusal)
y = a * e^(b*x)  (üstel)

Üstel büyüme (viral içerik, başarılı pazarlama kampanyası) varsa kapasite çok hızlı tükenir; planlamayı buna göre yapın.

Adım 3: Eşik & Aksiyon

Disk doluluk:
 %70  → uyarı, temizlik / arşiv
 %80  → upgrade siparişi planla
 %85  → ŞİMDİ upgrade yap
 %90  → kritik (servis durur)

Network port:
 %60 sürekli → büyük port düşün
 %70 sürekli → yedek port hazırla
 %80 zirve   → upgrade

CPU load:
 1.0 sürekli   → vCPU artır
 2.0 sürekli   → ÖNCELİKLİ upgrade

Buyukweb VDS planları vCPU, RAM, disk, port boyutlarında esnek upgrade destekler. Müşteri datasından kapasite eğrisi çıkarıp 60 gün önceden upgrade kararı verebiliyorsanız, müşterileriniz hiçbir zaman yavaş site görmez.

Buyukweb VDS Üzerinde Tek Sunucu İzleme Platformu

Buyukweb müşterileri için pratik öneri:

Senaryo 1: 5-20 host izleme (KOBİ)

Buyukweb VDS E5-V4 — 2 vCPU, 4 GB RAM, 80 GB SSD — ~₺250/ay
Uptime Kuma + Zabbix Agent 2 kurulumu
20-50 servis HTTP/TCP probe
Aylık ~₺250 yatırım, alarm e-posta + Telegram bot

Senaryo 2: 50-200 host izleme (Orta KOBİ)

Buyukweb VDS — 4 vCPU, 8 GB RAM, 160 GB SSD — ~₺450/ay
Zabbix Server + MariaDB + Zabbix Agent 2 kurulumu
Tüm sunucular agent ile push, switchler SNMPv3, dashboard Grafana
Aylık ~₺450 yatırım, alarm e-posta + SMS + webhook (Slack/Teams)

Senaryo 3: 500+ host izleme (Büyük)

Birden çok Buyukweb VDS — 1 ana Zabbix Server + 2-3 Zabbix Proxy
Coğrafi/segment bazlı proxy dağıtımı
TimescaleDB veya InfluxDB ile uzun süreli metric retention
Aylık ~₺1.500-3.000 yatırım, kurumsal operasyon

Tüm planlarda KVM sanallaştırma + tam root erişim olduğu için Zabbix, Nagios, Prometheus, Uptime Kuma, ne tercih ederseniz kurabilirsiniz. Günlük yedekleme (Veeam altyapısı) sayesinde izleme veritabanınız da güvende olur.

cPanel Paylaşımlı Hostingte İzleme Sınırları

cPanel hosting paketlerinde shell erişim sınırlı olduğu için kapsamlı izleme platformu kurulamaz. cPanel ortamında neyi izleyebilirsiniz?

cPanel'de Built-in İzleme

Resource Usage — son 24 saat CPU, RAM, IO, IOPS, EP grafiği
Errors — son 300 hata satırı
Bandwidth — aylık trafik kotası
Logs — /home/user/access-logs/, /home/user/logs/

cPanel İçin Dış İzleme

cPanel hostingde kendi izleme sunucunuz olmadığı için dış izleme servisleri tek seçenektir:

Uptime Kuma kendi VDS'inizde — HTTP/HTTPS probe, status sayfası
Cloudflare (DNS + CDN'iniz Cloudflare ise) — basit uptime + saldırı analitik

cPanel paketinizden ileri seviye metric çıkaramazsınız (CPU/RAM detayı, network detayı, log analiz). Bu noktaya gelirseniz VDS'e geçiş doğru karar olur.

Buyukweb Karar Matrisi: Hangi İzleme Stack'i Sizin İçin?

Senaryo	Önerilen	Yıllık/Aylık Tahmini
Tek site, sadece uptime kontrol	cPanel + dış Uptime Kuma	~₺350-500/yıl + ₺0
5-20 host, KOBİ	VDS + Uptime Kuma + Zabbix Agent	~₺250-350/ay
50-200 host, orta KOBİ	VDS + Zabbix Server full stack	~₺450-600/ay
200+ host, büyük	Çoklu VDS + Zabbix Proxy	~₺1.500-3.000/ay
Cloud-native, K8s ağırlıklı	VDS + Prometheus + Grafana	~₺450-600/ay
Sade dosya tabanlı klasik	VDS + Nagios Core	~₺250-400/ay

Fiyatlar tahminidir; güncel için paket karşılaştırma sayfamıza bakınız. KDV dahildir.

Sık Sorulan Sorular (SSS)

"Zabbix mi Prometheus mu seçeyim?"

İki sorunun cevabına göre karar verin: (1) SNMP ağırlıklı mı çalışıyorsunuz? Switch, router, UPS, yazıcı, klima izleyecekseniz Zabbix daha hazırdır. (2) Kubernetes/cloud-native ağırlıklı mı çalışıyorsunuz? Container/pod metric, service discovery, kısa süreli job için Prometheus daha doğal. Klasik sunucu/VDS dünyasında Zabbix çok daha az kurulum yorgunluğu sağlar; modern micro-service mimarisinde Prometheus yerleşik gelir. Karma ortamda Zabbix + Grafana (Zabbix datasource Grafana plugin) ikisinin iyi yanlarını birleştirebilirsiniz.

"Nagios hala kullanılır mı?"

Evet ama daralan bir çevrede. Nagios klasik Unix felsefesi sevenler, mevcut altyapısı çok eski olanlar, ve nagios plugin ekosistemini iyi bilen ekipler için hala makul. Yeni kurulumlarda yeni nesil (Zabbix / Prometheus / Icinga 2 — Nagios fork'u) tercih edilir. Eğitim materyali Nagios için fazla; konferans/topluluk Zabbix tarafında daha aktif.

"SNMPv1/v2c mı SNMPv3 mü?"

İç ağda kısa süre içinde v2c kullanmak hala mümkün ama orta vadede SNMPv3'e geçiş zorunlu kabul edilmelidir. Community string clear text yayınlandığı için iç saldırgan trafiği dinleyip community öğrenebilir ve cihazlara komut gönderebilir (özellikle "write community"). SNMPv3 SHA auth + AES privacy ile güvenli. Yeni cihaz alırken SNMPv3 desteği zorunlu kriter olsun.

"İzleme sunucumu nasıl izlerim? Kendi kendini görür mü?"

Klasik soru: "monitors monitorant quis custodiet?" İki yaklaşım: (1) iki izleme sunucusu birbirini izler — A sunucusu B'yi izler, B sunucusu A'yı izler, biri çökerse diğer alarm verir. (2) dış basit servis — Uptime Kuma'nızı bir status page sağlayıcıya kayıt edin, oradan da basit ping monitör yapın. (3) Cron + e-posta — basit bir cron script "izleme servisi yaşıyor mu" diye baksın, ölmüşse direk e-posta atsın. Üçü kombine en güvenli.

"NetFlow olmadan DDoS tespit edebilir miyim?"

Sınırlı. Bandwidth grafiği "trafik 10 Gbps oldu" der ama kimin saldırdığını söylemez. Çok kaynakli (1000+ IP) bir SYN flood sırasında NetFlow olmadan sadece top talkers (en çok trafik gönderenler) listesi çıkaramazsınız. Buyukweb VDS'lerinde standart DDoS L3+L4+L7 koruması veri merkezi seviyesinde aktiftir; uygulama seviyesinde extra koruma için Cloudflare gibi servisleri öneririz. Kritik kurumsal uygulamalar için kendi NetFlow collector'u (nfdump/nfsen veya ntopng) kurmak iyi olabilir.

"vnstat'a alternatif var mı? Daha modern?"

vnstat hala "iş görür" durumda ama modern alternatifler: netdata (real-time + tarihsel, çok güzel UI), Telegraf + InfluxDB + Grafana (DevOps stack), Prometheus node_exporter (cloud-native ekosistem). vnstat'ın en güçlü tarafı disk yer yok, RAM yok, CPU yok — sıfıra yakın yük. Sadece bandwidth ölçümü için hala 1. seçim.

"Alarm e-posta yerine Telegram bot kurulur mu?"

Evet, Zabbix'te webhook media type ile Telegram bot entegrasyonu standart hale geldi. BotFather'dan bot token alın, chat_id öğrenin, Zabbix Administration → Media types → Telegram webhook'ı yapılandırın. Açık kaynak script ve template örnekleri çok. SMS'e göre çok daha hızlı, çok daha ucuz (Telegram bot ücretsiz). Whatsapp Business API üzerinden de mümkün ama Telegram daha yaygın izleme topluluğu.

"Buyukweb destek hattı izleme konusunda yardım eder mi?"

VDS'iniz kurulu, kendi Zabbix/Prometheus stack'inizi siz kurarsınız (root sizde). Ancak 0850 302 60 70 destek hattımızdan: (a) VDS donanım/network durumu hakkında bilgi, (b) PTR/reverse DNS kaydı talebi, (c) DDoS olayı sonrası rapor, (d) ek IP/port/RAM upgrade gibi konularda destek alabilirsiniz. İzleme platformunun kendi yapılandırması müşterinin sorumluluğundadır — esnek, root tam erişim, KVM sanallaştırma sayesinde tamamen size aittir.

Sonuç ve Sonraki Adımlar

Ağ izleme ve bandwidth analizi, IT operasyonunun reaktiften proaktife geçişinin temel disiplinidir. Özet karar zinciri:

Linux native araçlarla başla — iftop, nethogs, nload, vnstat sunucunuzda kurulu olsun
SNMPv3 ile cihazları izle — switch, router, UPS, NAS, yazıcı
Bir izleme platformu seç — Zabbix (klasik geniş), Prometheus (cloud-native), Uptime Kuma (basit)
Buyukweb VDS üzerinde tek sunucu ile başla, gerekirse Zabbix Proxy ile ölçek
SLO + RED/USE method uygula, alarm fatigue'i önle
30 gün baseline + 90 gün trend ile kapasite planla
Backup MX, backup DNS, backup monitor — izleme sunucunuzu da izleyin

Tüm bunların altyapısı için Buyukweb VDS E5-V4 (KVM sanallaştırma, tam root erişim, %99.8 uptime, günlük Veeam yedek, standart DDoS koruması, Bursa Tier 3 veri merkezi) sağlam ve uygun maliyetli bir başlangıçtır. Aylık ₺250'dan başlayan fiyatlandırma ile büyük KOBİ'lere kadar tüm ölçeklerde izleme platformunuzu çalıştırabilirsiniz.

İlgili Büyükweb Hizmetleri

VDS Sunucu — Zabbix/Nagios/Prometheus self-host platformu (KVM, root erişim, KDV dahil ₺250/ay'dan)
cPanel Web Hosting — Site hosting paketleri (yıllık ₺350-2.000 KDV dahil)
Paket Karşılaştırma — Donanım/kaynak ihtiyacına göre paket seçimi
DDoS Koruma — L3/L4/L7 saldırı koruma altyapımız
Reverse DNS / PTR Rehberi — VDS PTR yönetimi
Yedekleme ve Felaket Kurtarma — Veeam tabanlı günlük yedek

Ağ izleme platformu kurulum planlaması, VDS donanım önerisi, bandwidth/trafik kotası danışmanlığı veya Buyukweb veri merkezi servisleri için 0850 302 60 70 numaralı destek hattımıza veya [email protected] adresine yazabilirsiniz. Çankaya/Ankara şirket merkezimiz ve Bursa Tier 3 veri merkezimiz, 2009'dan beri 17+ yıllık tecrübeyle Türkiye'nin internet altyapısına hizmet veriyor.