Saat gece yarısı üç. Telefonunuzun o ısrarcı, uykuyu bölen melodiyle çaldığını hayal edin. Arayan, nöbetçi sistem mühendisi arkadaşınız veya doğrudan otomatik izleme sisteminiz. Tek bir cümle duyuyorsunuz: “Ana veritabanı sunucusu çöktü, diski dolmuş.” Yarı uykulu gözlerle bilgisayarınızı açıyor, bir yandan kahve makinesine doğru sürünürken bir yandan da “Daha dün diskte %20 boş yer vardı, ne ara doldu?” diye kendi kendinize soruyorsunuz.
Sistem yöneticilerinin ve DevOps mühendislerinin hayatında bu senaryo bir kez bile yaşandıysa, izleme (monitoring) sistemlerinin sadece “çalışıyor/çalışmıyor” kontrolünden ibaret olmadığını anlamışızdır. Çoğu zaman standart şablonları kurup arkamıza yaslanırız. Ancak varsayılan Zabbix şablonları, sistemin can çekiştiği o gri alanları görmemizi sağlamaz. Linux sunucularınızın sessizce çığlık attığı anları yakalamak için daha derin, daha akıllı senaryolara ihtiyacımız var.
Aniden Doluveren Disklerin Arkasındaki Gizli Düşman: Inode Tüketimi
Zabbix panelinize baktığınızda disk doluluk oranının %40 olduğunu görüyorsunuz, her şey yolunda gibi. Fakat sunucunuz aniden “No space left on device” hatası vermeye başlıyor. Dosya oluşturulamıyor, servisler duruyor. İşte bu, Linux dünyasının en sinsi tuzaklarından biridir: Inode tükenmesi. Disk alanı bazında değil, dosya sayısı bazında sınırda olabilirsiniz.
Özellikle çok sayıda küçük dosya oluşturan e-posta kuyrukları, PHP oturum dosyaları veya mikro servis logları bu soruna yol açar. Zabbix üzerinde mutlaka vfs.fs.inode[/,pfree] anahtarını kullanarak bir tetikleyici (trigger) oluşturmalısınız. Inode serbest oranı %10’un altına düştüğünde alarm çalmalıdır ki, fiziksel disk alanınız olsa bile sistemsel olarak kilitlenmeyin.
Belleğin Yalancı Baharı: Swap Kullanımı ve OOM Killer
Linux, belleği (RAM) yönetme konusunda oldukça agresiftir. Boşta duran RAM’i önbellek (cache) olarak kullanır ve bu normaldir. Ancak fiziksel bellek gerçekten bittiğinde, Linux çekirdeği sistemi ayakta tutmak için acımasız bir karar alır: Out of Memory (OOM) Killer devreye girer ve en çok kaynak tüketen süreci (genellikle veritabanınızı) acımadan öldürür.
Sadece RAM kullanım yüzdesini izlemek sizi yanıltır. Gerçekten tetikte olmanız gereken iki metrik vardır:
- Swap Alanı Değişim Hızı: Swap alanının sadece dolu olması değil, aktif olarak ne hızla kullanıldığı (page-in/page-out oranları) önemlidir. Swap kullanımı aniden tırmanıyorsa, RAM yetmiyor demektir.
- OOM Killer Log Takibi: Zabbix log izleme ajanını
/var/log/messagesveya/var/log/syslogdosyalarında “Out of memory” veya “Killed process” kelimelerini arayacak şekilde yapılandırın. Bir servis durmadan önce çekirdeğin onu kurban etmek üzere olduğunu bu şekilde anlarsınız.
Zombi Süreçler ve İşlem Parçacığı Sınırları
Sunucu işlemcisi (CPU) stabil görünebilir, ancak sistemde çığ gibi büyüyen “Zombie” veya “Defunct” süreçler (processes) olabilir. Bu süreçler CPU kullanmaz ama sistemin işlem tablosunu (process table) işgal eder. Linux’un oluşturabileceği maksimum süreç sınırına (PID limit) ulaştığınızda, sunucuya yeni bir SSH bağlantısı bile yapamazsınız.
Zabbix’te varsayılan olarak gelen toplam süreç sayısının ötesine geçin. proc.num[,,zomb] anahtarı ile zombi süreçleri izleyin. Eğer bu sayı 5 veya 10’un üzerine çıkıyorsa, yazılımınızda sonlandırılmayan yetim alt süreçler var demektir. Bu durumu erkenden yakalamak, sunucunun yavaş yavaş felce uğramasını engeller.
Ağ Arayüzlerinde Gözden Kaçan Detay: Paket Hataları ve Droplar
Bant genişliği (bandwidth) kullanımınız kapasitenizin çok altında olabilir. Ancak bu, ağınızın sağlıklı olduğu anlamına gelmez. Hatalı yapılandırılmış bir switch portu veya eskiyen bir ağ kablosu, paketlerin yolda kaybolmasına (packet drop) neden olur. Uygulamalarınız yavaş yanıt verir ama görünürde CPU ve RAM normaldir.
Çözüm, ağ kartındaki hata oranlarını izlemektir. Zabbix üzerinde ilgili ağ arayüzü için net.if.in[if,errors] ve net.if.out[if,errors] değerlerini takibe alın. Saniyede 5’ten fazla hata veya drop alınan bir senaryo, fiziksel veya sanal ağ katmanında bir şeylerin ters gittiğinin en net kanıtıdır.
Sistem Yükünün (Load Average) CPU Çekirdek Sayısıyla Dansı
Load Average değerinin 10 olduğunu gördüğünüzde panik yapar mısınız? Bu sorunun cevabı sunucunuzun mimarisinde saklıdır. 2 çekirdekli bir sunucu için 10 yük değeri felaket anlamına gelirken, 32 çekirdekli bir sunucu için bu değer sistemin neredeyse yattığını gösterir.
Zabbix trigger kurallarınızı statik yük değerlerine göre yazmaktan vazgeçin. Bunun yerine yük değerini, aktif CPU çekirdek sayısına oranlayan esnek formüller kullanın. Sistem yükü, çekirdek sayısının 1.5 katını aştığında tetiklenecek bir kural, sizi gereksiz alarmlardan kurtaracak ve sadece gerçek darboğazlarda uyaracaktır.
Zaman Sapması: Görünmez Senkronizasyon Bozuklukları
Dağıtık mimarilerde, cluster yapılarında veya mikro servislerde sunucu saatlerinin birbirleriyle milisaniyelik hassasiyette uyumlu olması gerekir. Bir sunucunun saati diğerinden sadece 3 saniye geri kaldığında, SSL sertifikası doğrulama hataları, veritabanı replikasyon gecikmeleri ve log analiz karmaşası başlar.
Zabbix ajanının system.localtime verisini, Zabbix sunucusunun kendi saatiyle karşılaştıran bir senaryo kurun. İki zaman dilimi arasındaki fark 1 saniyeyi aştığında sistem sizi uyarmalıdır. NTP (Network Time Protocol) servisinin çalışıp çalışmadığını doğrulamak, sistem kararlılığı için hayati bir adımdır.
Dosya Sistemi Salt Okunur (Read-Only) Olduğunda
Sanal makine altyapılarında veya disk donanımı arızalarında, Linux çekirdeği veriyi korumak için dosya sistemini aniden “Read-Only” (salt okunur) moduna alabilir. Bu durumda sunucu çalışıyor görünür, ping atabilirsiniz ama hiçbir servis diske yazamaz. Web siteniz hata verir, veritabanınız çöker.
Bunu tespit etmek için basit ama dahiyane bir senaryo uygulayabilirsiniz. Belirli aralıklarla geçici dizine küçük bir dosya yazmayı deneyen ve yazamazsa hata dönen küçük bir Zabbix UserParameter betiği yazın. Alternatif olarak, /proc/mounts dosyasındaki disk mount seçeneklerinde “ro” (read-only) ibaresinin geçip geçmediğini taratın.
Sessizce Büyüyen Tehdit: Log Dosyalarının Rotasyon Hatası
Logrotate servisi Linux sunucuların can simididir. Ancak bazen bir yapılandırma hatası veya izin sorunu nedeniyle log dosyaları dönmeyi (rotate) bırakır. Birkaç gigabaytlık tek bir log dosyası hem okuma/yazma performansını düşürür hem de disk alanını hızla tüketir.
Zabbix ile kritik log dosyalarının (örneğin /var/log/nginx/access.log veya uygulama logları) boyutunu izleyin. Eğer bir log dosyasının boyutu son 24 saat içinde hiç küçülmediyse ve sürekli büyüyerek kritik sınırları aştıysa, logrotate mekanizmanız bozulmuş demektir. Bu senaryo, büyük felaketleri daha büyümeden engeller.
SSH Giriş Denemeleri ve Brute Force Saldırıları
Dış dünyaya açık bir Linux sunucunuz varsa, saniyede onlarca brute force (kaba kuvvet) saldırısına maruz kalıyor olabilirsiniz. Bu saldırılar sunucuyu ele geçiremese bile ciddi CPU ve ağ kaynağı tüketir, logları kirletir.
Zabbix log izleme yeteneğini kullanarak /var/log/auth.log (RedHat türevlerinde /var/log/secure) dosyasını tarayın. “Failed password for” ifadesini içeren satırları saydırın. Eğer son 5 dakikada başarısız giriş denemesi sayısı 30’u geçiyorsa, bu bir saldırı belirtisidir. Entegrasyonlarınızı bir adım öteye taşıyarak, bu alarm tetiklendiğinde Zabbix’in otomatik olarak Fail2ban veya güvenlik duvarı kurallarını tetiklemesini sağlayabilirsiniz.
Zombi Süreçlerden Daha Tehlikeli: Systemd Servis Durumları
Bir sunucunun ayakta olması, üzerindeki servislerin düzgün çalıştığı anlamına gelmez. Apache, Nginx, MySQL veya Docker servisi arka planda çökmüş ve “failed” durumuna düşmüş olabilir. Sadece port kontrolü yapmak bazen yetersiz kalır.
Zabbix’in yerel systemd.unit.info anahtarını kullanarak kritik servislerin aktif durumlarını izleyin. Bir servisin durumu “active (running)” dışına çıktığı anda haberdar olun. Hatta Zabbix’in “Remote Command” özelliğini kullanarak, servis çöktüğünde önce otomatik olarak systemctl restart komutunu çalıştırmasını, eğer servis yine de ayağa kalkmazsa size alarm göndermesini sağlayabilirsiniz.
Unutmayın, en iyi izleme sistemi, size hiç alarm göndermeyen değil; sadece gerçekten harekete geçmeniz gerektiğinde, sorunun kaynağını doğrudan söyleyerek sizi uykunuzdan uyandıran sistemdir. Kurduğunuz bu 10 senaryo ile sunucularınızın dilini daha iyi anlayacak, o gece yarısı telefonlarını bir daha hiç almama yolunda dev bir adım atmış olacaksınız; sizce de bu huzur, ufak bir yapılandırma mesaisine değmez mi?