Sunucu İzleme: Zabbix, Netdata ve Uptime Kuma Hangisi Size Uygun?

Kısa cevap: Sunucu izleme, bir sistemin erişilebilirliğini ve kaynak durumunu sürekli ölçüp eşik aşıldığında uyarı üreten katmandır. Tek gerçek ölçütü şudur: bir şey bozulduğunda bildirim gerçekten ulaşıyor mu? Minimum sette dört şey izlenir: erişilebilirlik, disk doluluğu, bellek ile yük, TLS sertifikası bitişi. Araç seçimi ölçeğe göre yapılır: tek sunucuda Netdata ve Uptime Kuma yeterlidir, on cihazı geçen ortamda Zabbix gerekir.

İzlemenin amacı nedir: grafik mi, uyarı mı?

Bu ayrım kurulumun tamamını belirler. İki farklı ihtiyaç vardır ve çoğu kişi ikincisini kurmadan birincisiyle yetinir:

• Gözlem (grafik): Sistem nasıl davranıyor, yük ne zaman artıyor, kapasite ne zaman biter. Planlama ve teşhis içindir.
• Uyarı (alerting): Şu anda bir şey bozuk ve birinin müdahale etmesi gerekiyor. Operasyon içindir.

Güzel panolar kurup uyarı zincirini kurmamak yaygın bir hatadır; çünkü panolar tatmin edici, uyarı zinciri ise sıkıcı bir iştir. Oysa gece üçte diski dolan bir sunucudan haberdar olmanızı sağlayan şey pano değil, çalıştığı test edilmiş bir bildirim zinciridir.

Pratik test: izleme sisteminizi kurduktan sonra kasten bir arıza yaratın (bir servisi durdurun) ve bildirimin telefonunuza ulaşmasını bekleyin. Ulaşmıyorsa izleme yok demektir. Bu testi altı ayda bir tekrarlayın; bildirim kanalları sessizce bozulur (kotası dolan bir API anahtarı, değişen bir webhook adresi, spam klasörüne düşen e-posta).

Bir sunucuda minimum hangi metrikler izlenir?

Her sunucuda kurulacak dört başlık ve sahada işe yarayan eşik değerleri:

Metrik	Uyarı eşiği	Kritik eşik	Neden
Disk doluluğu	%80	%90	En sık kesinti nedeni; dolan diskte servisler yazamaz ve veritabanı bozulabilir
Erişilebilirlik	2 ardışık başarısız kontrol	5 dakika kesintisiz	Tek kaçırılan kontrol geçici ağ dalgalanması olabilir
Bellek	%85 kullanım	Takas alanı aktif kullanımda	Takas kullanımı başladığında performans çöker
Yük ortalaması	Çekirdek sayısı	Çekirdek sayısının 2 katı	Mutlak sayı değil, çekirdeğe oranla anlamlı
Sertifika bitişi	21 gün kaldı	7 gün kaldı	Otomatik yenileme bozulduğunda tek uyarı budur

Disk doluluğunda yüzdeden daha değerli bir metrik büyüme hızıdır. %75’te sabit duran bir disk sorun değildir; %60’tan %70’e bir haftada çıkan disk, üç hafta içinde dolacak demektir. Zabbix bu tür öngörüyü forecast fonksiyonuyla doğrudan hesaplayabilir ve doluluk eşiğine gelmeden önce uyarır.

Sertifika izlemesi listede beklenmedik biçimde önemlidir. Let’s Encrypt otomatik yenilemesi kurulmuş sistemlerde bile yenileme sessizce bozulabilir (değişen DNS, dolan disk, kapanan 80 portu). Sertifika bitiş tarihini bağımsız olarak izlemek, bu sessiz arızayı yakalayan tek mekanizmadır.

Disk konusunda gözden kaçan bir kaynak da sistem günlükleridir. journald varsayılan yapılandırmada disk alanının bir kısmına kadar büyüyebilir; sınırı açıkça belirlemek iyi bir alışkanlıktır:

# /etc/systemd/journald.conf içinde
SystemMaxUse=2G

Zabbix, Netdata ve Uptime Kuma: hangisi ne için?

Üçü rakip değil, farklı katmanlardır. Karıştırıldıklarında yanlış aracı yanlış işe koşmuş olursunuz.

Ölçüt	Uptime Kuma	Netdata	Zabbix
Ne yapar	Dışarıdan erişilebilirlik kontrolü	Saniyelik çözünürlükte yerel metrik	Merkezî izleme, eşik, uyarı, envanter
Kurulum süresi	Dakikalar	Dakikalar	Saatler
Yapılandırma yükü	Çok düşük	Düşük	Yüksek
Uzun vadeli veri	Sınırlı	Sınırlı (varsayılan)	Güçlü (yıllar)
Uyarı esnekliği	Basit	Orta	Çok yüksek (eskalasyon, bakım penceresi)
Ağ cihazı izleme (SNMP)	Yok	Sınırlı	Güçlü
Ölçek	Onlarca kontrol	Sunucu başına	Binlerce cihaz

Seçim önerim:

• 1-3 sunucu, kişisel veya küçük proje: Uptime Kuma (dışarıdan erişilebilirlik) artı Netdata (teşhis). Toplam kurulum yarım gün, ihtiyacın büyük kısmını karşılar.
• Sunucu ve ağ cihazı karışık, 10+ nokta: Zabbix. Özellikle router ve switch’leri SNMP ile aynı sistemde izlemek istiyorsanız alternatifi yok denecek kadar azdır; MikroTik tarafındaki kurulumu MikroTik Zabbix SNMP izleme yazısında ayrıntılandırdım.
• Konteyner yoğun ortam: Netdata konteyner metriklerini otomatik keşfeder; kalıcı depolama ve uyarı için Zabbix veya Prometheus ile birlikte kullanılır.

Kendi altyapımda bu üçlü ayrımı fiilen kullanıyorum: ağ cihazları ve sunucular merkezî bir Zabbix üzerinde, tek tek makinelerde anlık teşhis için Netdata, dışarıdan bağımsız erişilebilirlik kontrolü için ayrı bir ağda duran hafif bir kontrol noktası. Üçünün üst üste binen kısmı israf değil, sigortadır: izleme sisteminin kendisi bozulduğunda haber veren şey diğeridir.

İzleme sunucusu nereye kurulur?

Kritik kural: izleme sistemi, izlediği makine ile aynı arıza alanında olmamalıdır.

Aynı sunucuya kurulmuş bir izleme, sunucu çöktüğünde birlikte çöker ve size kimse haber vermez. Aynı şey aynı hipervizör, aynı elektrik hattı ve aynı internet bağlantısı için de geçerlidir. Uygulanabilir kurgu şudur:

• İç metrikler (disk, bellek, servis durumu) merkezî izleme sunucusundan toplanır; bu sunucu izlenen makinelerden farklı bir fiziksel makinede durur.
• Dış erişilebilirlik tamamen farklı bir ağdan kontrol edilir; ucuz bir VPS veya barındırılan bir kontrol servisi bu iş için yeterlidir.
• İzleme sunucusunun kendisi de izlenir: en basitiyle, izleme sunucusundan düzenli bir “hayattayım” sinyali beklenir ve sinyal kesilirse uyarı üretilir.

Sanallaştırma kullanıyorsanız izleme makinesini ayrı bir sanal makinede tutup düzenli snapshot almak pratik bir orta yoldur; kurulumu için Proxmox VE kurulum rehberine bakabilirsiniz. Yine de hipervizörün kendisinin arızalanma ihtimalini kapatmaz; dış erişilebilirlik kontrolü mutlaka başka bir yerde durmalıdır.

Uyarı zinciri: bildirim gerçekten ulaşıyor mu?

Uyarı kurgusunun üç bileşeni vardır ve üçü de test edilmelidir: tetikleyici (ne zaman), kanal (nereye), eskalasyon (cevap gelmezse ne olur).

Kanal seçiminde pratik ayrım:

Önem	Kanal	Beklenen tepki
Kritik (servis durdu, disk %90)	Telefon bildirimi veya anlık mesaj	Hemen
Uyarı (disk %80, sertifika 21 gün)	E-posta veya mesaj grubu	Aynı gün
Bilgi (yeniden başlatma, yedek tamamlandı)	Günlük özet	Bakılır, uyarı üretmez

En sık yapılan hata her şeyi aynı kanaldan göndermektir. Kritik uyarının, günde yirmi bilgi mesajı gelen bir kanala düşmesi, o uyarının görülmemesi demektir. Bu, uyarı yorgunluğunun tam tanımıdır: sistem sürekli bağırdığı için kimse dinlemez.

Uyarı yazarken üç kuralı uygulayın:

1. Her uyarı bir eylem gerektirmeli. “CPU %70” bilgidir, uyarı değildir. Uyarı, birinin kalkıp bir şey yapmasını gerektiren durumdur.
2. Eşik gerçek davranışa göre ayarlanmalı. Bir hafta veri topladıktan sonra eşiği belirleyin; teoriden atılan eşik ya sürekli tetiklenir ya hiç tetiklenmez.
3. Bakım penceresi tanımlayın. Planlı yeniden başlatmaların uyarı üretmemesi gerekir; her planlı bakımda gelen sahte uyarı, gerçek uyarıya duyarsızlaşmanın en hızlı yoludur.

Bir de sık atlanan ayrıntı: uyarı mesajının içeriği. “Sunucu sorunlu” mesajı işe yaramaz. İyi bir uyarı şunları içerir: hangi makine, hangi metrik, şu anki değer, eşik değeri ve mümkünse doğrudan ilgili panele bir bağlantı. Gece üçte uyanan kişinin, tanı koymak için ayrıca araştırma yapması gerekmemelidir.

Loglar neden ayrıca izlenmeli?

Metrikler “ne kadar” sorusunu cevaplar, loglar “ne oldu” sorusunu. İkisi birbirinin yerine geçmez.

Minimum log disiplini üç maddedir:

# 1) Sistem loglarına hızlı bakış (son 1 saatteki hatalar)
sudo journalctl -p err --since "1 hour ago"

# 2) Bir servisin canlı takibi
sudo journalctl -u nginx -f

# 3) Disk kullanımını sınırla (log dosyaları diski doldurabilir)
sudo journalctl --disk-usage
sudo journalctl --vacuum-size=1G

Birden fazla sunucuda çalışıyorsanız logların merkezî bir yerde toplanması gerekir; makinelere tek tek girip log aramak üç sunucudan sonra sürdürülemez ve bir makine tamamen çöktüğünde son logları kaybedersiniz. Merkezî log toplama, güvenlik olayı incelemesi için de zorunludur: saldırgan yerel logları silebilir, uzaktaki kopyayı silemez.

Başarısız SSH giriş denemelerinin izlenmesi bu başlığın güvenlik ayağıdır; SSH sertleştirme yazısında hangi kalıpların normal, hangilerinin dikkat gerektirdiğini anlattım.

İzleme kurulumu nasıl doğrulanır?

İzleme kurulumunun bittiğini şu beş kontrol söyler:

• Kasten yaratılan bir arıza (servis durdurma) bildirim üretti ve bildirim telefonunuza ulaştı
• Disk, bellek, yük ve sertifika eşikleri tanımlı ve gerçekçi
• İzleme sistemi, izlediği makinelerden farklı bir arıza alanında
• İzleme sisteminin kendisi izleniyor (sessizlik uyarı üretiyor)
• Bakım penceresi tanımlanabiliyor, planlı işler sahte uyarı üretmiyor
• Uyarı mesajı makine adı, metrik, değer ve eşik içeriyor
• Log disk kullanımı sınırlı, merkezî toplama (çok sunuculu ortamda) kurulu
• Bildirim testi takvime alındı (altı ayda bir tekrar)

Bu liste kapandığında sunucu yönetiminin dördüncü katmanı tamamlanmış olur. Beşinci katman yedekleme ve geri yükleme testidir; sanallaştırma kullanıyorsanız Proxmox yedekleme ve snapshot rehberi bu işi ciddi biçimde ucuzlatır. Katmanların tamamı ve sırası Linux sunucu yönetimi yol haritasında.

Çok sayıda sunucu ve ağ cihazını tek merkezden izlemek gerekiyorsa sistem yönetimi ve network yönetimi hizmet sayfalarında bu kurgunun kurumsal ölçekte nasıl işletildiğini anlattım.

Kaynaklar

• Zabbix Documentation (tetikleyici ifadeleri, eskalasyon, bakım penceresi)
• RFC 3411: SNMP Architecture (ağ cihazı izlemesinin protokol temeli)
• journald.conf manual (log disk kullanımı sınırları)