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?
Gerekçesi aslında oldukça basit. Bir olay (örneğin bir güvenlik ihlali ya da port flapping) gerçekleştiğinde, hangi cihazda olduğunu tek tek aramak yerine tek bir arayüzden sorgu atabiliyorsunuz. Switch’in kendi log belleği zaten sınırlı ve yeniden başlatıldığında kayboluyor — merkezi sunucuda ise kayıt kalıcı oluyor. Belki de en değerlisi: birden fazla cihazdaki olayları aynı zaman çizelgesinde ilişkilendirebiliyorsunuz (correlation), ki bu tek başına birçok sorunu çözüyor.
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.
Bir Flapping Port Örneği
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.
Pratikte Fark Ne Yaratıyor
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ım haline geliyor.