Kurumsal bir ağda 10, 20, belki 50 switch varsa, her birinin loglarını tek tek SSH ile bağlanıp kontrol etmek sürdürülebilir değildir. Çözüm, tüm cihazların loglarını merkezi bir syslog sunucusuna yönlendirmektir.
Neden Merkezi Log Yönetimi?
- Bir olay (örn. güvenlik ihlali, port flapping) gerçekleştiğinde, hangi cihazda olduğunu aramak yerine tek bir arayüzden arama yapabilirsiniz
- Switch’in kendi log belleği sınırlıdır ve yeniden başlatıldığında kaybolur — merkezi sunucuda kalıcı kayıt tutulur
- Birden fazla cihazdaki olayları zaman çizelgesinde ilişkilendirmek (correlation) mümkün hale gelir
Cisco Switch Tarafında Yapılandırma
Switch(config)# logging host 192.168.1.100 Switch(config)# logging trap informational Switch(config)# logging source-interface vlan 1 Switch(config)# logging facility local6 Switch(config)# service timestamps log datetime msec localtime
logging trap informational, hangi seviyedeki olayların gönderileceğini belirler. Seviyeler ciddiyet sırasına göre: emergency(0), alert(1), critical(2), error(3), warning(4), notification(5), informational(6), debugging(7). Üretim ortamında genellikle informational (6) seviyesi, gürültü ile önem arasında iyi bir denge sağlar.
Syslog Sunucu Tarafı Seçenekleri
Merkezi toplama için kullanılabilecek başlıca seçenekler: açık kaynak rsyslog/syslog-ng (Linux tabanlı, esnek), ya da daha kapsamlı log analiz platformları (Graylog, ELK/Elastic Stack). Küçük-orta ölçekli bir ortamda rsyslog + basit bir arama arayüzü çoğu zaman yeterlidir.
Anlamlı Filtreleme: Gürültüyü Azaltmak
Ham log akışı hızla “gürültüye” dönüşebilir. Sahada en çok değer gördüğüm filtreleme yaklaşımı, kritik olay türlerine (interface down/up, port-security violation, config değişikliği, STP topology change) göre ayrı uyarı kuralları tanımlamak; rutin/bilgilendirici logları ise sadece arşivlemek.
Sahadan Bir Örnek: Flapping Port Tespiti
Bir switch portunun sürekli up/down durumuna geçtiği (flapping) bir durumda, tek bir switch’e bakarken bunu fark etmek zor olabilir — ama merkezi syslog’da bu port için gelen tekrarlayan “%LINK-3-UPDOWN” mesajlarını zaman bazlı gruplandığında, sorun net şekilde ortaya çıkar. Kök neden genellikle kötü bir kablo veya arızalı bir SFP modülüdür.
Sonuç
Merkezi syslog altyapısı kurmak, başlangıçta ek bir efor gibi görünse de, ağ genişledikçe “hangi cihazda ne oldu” sorusuna saniyeler içinde cevap verebilmenizi sağlayan, vazgeçilmez bir operasyonel yatırımdır.