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

Ağ İzleme ve Bandwidth Analizi: SNMP, NetFlow ve Kapasite Planlama Rehberi

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, bir sistem yöneticisinin kavramsal temel + Linux native araçlar + paket analizi + SNMP + NetFlow/sFlow/IPFIX + kapasite planlama konularında bilmesi gereken her şeyi tek dosyada topluyor. Bu ham veriyi bir izleme platformuna (Zabbix, Nagios, Prometheus) taşıyıp adım adım kurulum, alarm ve eskalasyon yapılandırmasına geçmek isterseniz ayrı ve kapsamlı rehberimize bakabilirsiniz: Zabbix ve Nagios: Sunucu İzleme, Kurulum ve Alarm Yönetimi.

Büyükweb perspektifi: İstanbul Tier III sertifikalı DataCasa veri merkezimizdeki VDS E5-V4 sunucularımız, VMware vSphere sanallaştırma ile tam root erişim sağlar. Aylık ₺250-600 arası seviyeden başlayan bu sunucularda SNMP agent, NetFlow collector veya tercih ettiğiniz izleme platformunu özgürce kurabilir, kendi trafiğinizi baştan sona ölçebilirsiniz. Standart DDoS L3+L4+L7 koruması, %99.8 uptime ve günlük yedekleme ile izleme altyapınız da güvende olur. Detay ve uygun paket için 0850 302 60 70 veya destek@buyukweb.com.

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 Büyükweb 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.

Ham Veriden Alarm ve Dashboard'a: İzleme Platformu Seçimi

SNMP OID'leri, NetFlow kayıtları ve Linux CLI çıktıları tek başına ham veridir. Bunları saklayan, eşik (threshold) tanımlayan, alarm üreten ve dashboard'da görselleştiren bir izleme platformu gerekir. Açık kaynak dünyasında öne çıkan seçenekler:

• Zabbix — Web UI + veritabanı tabanlı yapılandırma, SNMP ve flow verisiyle native entegre çalışır, auto-discovery güçlüdür. Yeni kurulumlar ve SNMP ağırlıklı (switch/router/UPS) ortamlar için ilk tercih.
• Nagios — Dosya tabanlı (.cfg) yapılandırma, geniş plugin ekosistemi (check_snmp, check_traffic vb.). Klasik Unix felsefesini ve mevcut plugin yatırımını sürdürmek isteyenler için.
• Prometheus + Grafana — Pull tabanlı, cloud-native/Kubernetes ortamlarda fiili standart (aşağıda detaylandırılıyor).
• Uptime Kuma — Sade, self-host bir availability/durum sayfası aracı (HTTP/TCP/ICMP probe + bildirim + public status page). SNMP/NetFlow gibi derin metrik sunmaz; sadece "site açık mı" sorusuna hızlı cevap arıyorsanız yeterlidir.

Bu platformlardan birini Büyükweb VDS üzerinde kendi sunucunuzda kurup işletebilirsiniz (VMware vSphere sanallaştırma, tam root erişim). Zabbix veya Nagios'u sıfırdan kurmak, host/agent/template/trigger/action zincirini yapılandırmak ve alarm eskalasyonunu (SMS, Telegram, e-posta) devreye almak için adım adım rehberimize bakın: Zabbix ve Nagios: Sunucu İzleme, Kurulum ve Alarm Yönetimi.

Prometheus + Grafana: Pull vs Push Modeli

Modern cloud-native dünyada Prometheus + Grafana stack'i de değerlendirilmelidir; bu ikili özellikle pull/push mimari tercihini netleştirmesi açısından yukarıda anlattığımız SNMP (pull) ve NetFlow (export/push) kavramlarını bir arada görmek için iyi bir referans noktasıdır.

Prometheus

• Pull tabanlı — Prometheus kendisi agent'lara/exporter'lara bağlanır ve metric çeker (SNMP GET mantığına benzer)
• 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, SNMP GET)	Push (NetFlow export, Zabbix sender)
Network mimari	Server agent'a/cihaza ulaşır	Agent/cihaz server'a veri gönderir
Firewall karmaşıklığı	Server inbound delik gerek	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
• 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.

Alarm Fatigue: SLO, SLI, RED Method

Hangi izleme platformunu (Zabbix, Nagios, Prometheus) seçerseniz seçin, aynı disiplin sorunuyla karşılaşırsınız: ç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 sözleşmesel yaptırım 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

Büyükweb 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.

Büyükweb VDS Üzerinde Tek Sunucu İzleme Platformu

Büyükweb müşterileri için pratik öneri:

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

• Büyükweb VDS E5-V4 — 2 vCPU, 4 GB RAM, 80 GB SSD — ~₺250/ay
• Uptime Kuma + SNMP tabanlı temel metrik toplama
• 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İ)

• Büyükweb VDS — 4 vCPU, 8 GB RAM, 160 GB SSD — ~₺450/ay
• Zabbix Server + MariaDB + Zabbix Agent 2 kurulumu (detay: Zabbix ve Nagios kurulum rehberi)
• 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 Büyükweb 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 VMware vSphere sanallaştırma + tam root erişim olduğu için Zabbix, Nagios, Prometheus, Uptime Kuma, ne tercih ederseniz kurabilirsiniz. Günlük yedekleme 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, SNMP/NetFlow verisi). Bu noktaya gelirseniz VDS'e geçiş doğru karar olur.

Büyükweb 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 + SNMP	~₺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. Zabbix kurulum adımları için kapsamlı rehberimize bakabilirsiniz.

"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. Nagios'un mimarisi, plugin sistemi ve alarm eskalasyonu hakkında detay için Zabbix ve Nagios karşılaştırma rehberimize bakabilirsiniz.

"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 kaynaklı (1000+ IP) bir SYN flood sırasında NetFlow olmadan sadece top talkers (en çok trafik gönderenler) listesi çıkaramazsınız. Büyükweb 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, çoğu izleme platformunda (Zabbix, Uptime Kuma, Prometheus Alertmanager) webhook media type ile Telegram bot entegrasyonu standart hale geldi. BotFather'dan bot token alın, chat_id öğrenin, ilgili platformun bildirim ayarlarından Telegram webhook'ını yapılandırın. Zabbix özelinde adım adım kurulum için Zabbix/Nagios rehberimize bakabilirsiniz. SMS'e göre çok daha hızlı, çok daha ucuz (Telegram bot ücretsiz).

"Büyükweb 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, VMware vSphere 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:

1. Linux native araçlarla başla — iftop, nethogs, nload, vnstat sunucunuzda kurulu olsun
2. SNMPv3 ile cihazları izle — switch, router, UPS, NAS, yazıcı
3. Flow analizine geç — NetFlow/sFlow/IPFIX ile kim-kime-ne kadar trafik gönderiyor sorusuna cevap bul
4. Bir izleme platformu seç — Zabbix (klasik geniş), Prometheus (cloud-native), Uptime Kuma (basit); kurulum adımları için Zabbix ve Nagios rehberimize bakın
5. SLO + RED/USE method uygula, alarm fatigue'i önle
6. 30 gün baseline + 90 gün trend ile kapasite planla
7. Backup MX, backup DNS, backup monitor — izleme sunucunuzu da izleyin

Tüm bunların altyapısı için Büyükweb VDS E5-V4 (VMware vSphere sanallaştırma, tam root erişim, %99.8 uptime, günlük yedek, standart DDoS koruması, İstanbul Tier III sertifikalı DataCasa 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

• Zabbix ve Nagios: Sunucu İzleme, Kurulum ve Alarm Yönetimi — Adım adım kurulum, template/trigger/action ve alarm eskalasyonu
• VDS Sunucu — SNMP/NetFlow/Zabbix/Nagios self-host platformu (VMware vSphere, 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 — Günlük otomatik yedek

Ağ izleme platformu kurulum planlaması, VDS donanım önerisi, bandwidth/trafik kotası danışmanlığı veya Büyükweb veri merkezi servisleri için 0850 302 60 70 numaralı destek hattımıza veya destek@buyukweb.com adresine yazabilirsiniz. Çankaya/Ankara şirket merkezimiz ve İstanbul Tier III sertifikalı DataCasa veri merkezimiz, 2009'dan beri 17+ yıllık tecrübeyle Türkiye'nin internet altyapısına hizmet veriyor.