Ağ izleme projelerinin çoğu aynı şekilde başarısız olur. Yazılım kurulur, cihazlar keşfedilir, varsayılan uyarılar açılır. İlk hafta e-posta kutusuna yüzlerce uyarı düşer. İkinci hafta biri bunlar için bir kural yazıp ayrı klasöre taşır. Bir ay sonra kimse o klasörü açmaz ve gerçek bir arıza, yine bir kullanıcının telefonuyla fark edilir. Sorun yazılımda değil, ilk 30 günün planlanmamasındadır. Bu yazıda örnekleri ManageEngine OpManager üzerinden veriyoruz ama anlattığımız sıra, hangi izleme aracını kullanırsanız kullanın geçerlidir. İzleme yaklaşımımızın bütünü için ağ ve sunucu izleme sayfamıza bakabilirsiniz.
Başlamadan önce: iyi bir uyarının üç özelliği
Her uyarı kurulmadan önce şu üç soruyu geçmelidir:
- Eyleme dönüşüyor mu? Uyarıyı alan kişi bir şey yapmalı. Yapacak bir şey yoksa bu bir uyarı değil, rapordur.
- Doğru kişiye mi gidiyor? Depolama uyarısı sistem yöneticisine, hat uyarısı ağdan sorumlu kişiye gitmeli. Herkese giden uyarı kimseye gitmemiş sayılır.
- Önem derecesi doğru mu? Gece yarısı birini uyandıracak uyarılar ile ertesi sabah bakılacaklar ayrılmalı. OpManager uyarıları Attention, Trouble ve Critical olarak üç seviyede sınıflandırır; bu ayrımı bilinçli kullanın.
1. hafta: envanter, kritik liste ve bağımlılıklar
İlk hafta uyarı kurmaya değil, neyi izlediğinizi anlamaya ayrılmalıdır.
- Keşfi yapın ve temizleyin. Otomatik keşif ağdaki her şeyi bulur: yazıcılar, IP telefonlar, misafir cihazları. Hangilerinin izleneceğine karar verin.
- Kritik sistem listesini çıkarın. İnternet çıkışı, güvenlik duvarı, çekirdek anahtar, sanallaştırma sunucuları, etki alanı denetleyicisi, ERP ve muhasebe veritabanı, dosya sunucusu, yedekleme sunucusu. Bu liste, uyarı önceliklerinin temelidir.
- Bağımlılıkları tanımlayın. Bir şubenin güvenlik duvarı düştüğünde arkasındaki yirmi cihazın ayrı ayrı alarm vermesi, asıl sorunu kalabalığın içinde kaybettirir. OpManager’da uplink bağımlılığı tanımlandığında üst cihaz düştüğünde tek bir alarm üretilir, arkadaki cihazlar “Dependent Unavailable” olarak işaretlenir.
- Kimlik bilgilerini güvenli kurun. Ağ cihazlarında SNMPv3, Windows sunucularda WMI, Linux sunucularda SNMP ya da SSH ile veri toplanır. SNMP’yi güvenli yapılandırmayı SNMP ile ağ izleme yazımızda anlattık.
2. hafta: temel uyarılar
Bu hafta, her kurumun ilk gün ihtiyaç duyduğu küçük bir uyarı setini devreye alın. Aşağıdaki eşikler başlangıç noktasıdır; ilk haftalardaki veriye göre ayarlanmalıdır.
| Ne izlenir? | Neden? | Başlangıç önerisi |
|---|---|---|
| Kritik cihaz erişilebilirliği | Kesintiyi kullanıcılardan önce görmek | Birkaç ardışık yoklamada cevap yoksa Critical |
| Disk doluluğu | Dolan disk veritabanını, e-postayı ve yedeği durdurur | Örneğin %80’de uyarı, %90’da kritik |
| Kritik Windows servisleri | Sunucu ayakta ama uygulama durmuş olabilir | SQL Server, yedekleme ajanı gibi servisler durduğunda uyarı |
| İnternet ve şube hatlarının doluluğu | Yavaşlık şikâyetlerinin en yaygın kaynağı | Uzun süre yüksek seyreden kullanımda uyarı |
| Arayüz hata sayaçları | Arızalı kablo ya da port, kesintiden önce hata üretir | Hata artışında uyarı |
| Donanım sağlığı | Fan, güç kaynağı, RAID ve sıcaklık sorunları erken belirti verir | Üretici durum bilgisi “normal” dışına çıktığında uyarı |
| UPS | Elektrik kesintisinde ne kadar süreniz olduğunu bilmek | Aküye geçiş ve düşük akü durumunda uyarı |
Yedekleme sunucusunun diskini ve yedekleme servislerini bu ilk sete mutlaka dahil edin. Sessizce duran bir yedek, ancak geri yükleme gerektiğinde fark edilir. Sistem odasının sıcaklık ve nemini de aynı düzene almak için sistem odası sıcaklık ve nem yazımıza göz atabilirsiniz.
3. hafta: gürültüyü ayıklayın
İki haftalık veri, hangi uyarıların işe yaradığını gösterir. Bu hafta her uyarıya tek tek bakın:
- Tekrar eden ama kimsenin müdahale etmediği uyarılar: Eşiği yanlıştır, yanlış kişiye gidiyordur ya da hiç gerekli değildir.
- Belirli saatlerde gelen uyarılar: Gece yedekleme sırasında dolan hat ya da ay sonu kapanışında yükselen veritabanı sunucusu işlemcisi normaldir. OpManager’ın uyarlanabilir eşikleri, makine öğrenimiyle saatlik, günlük ve haftalık döngüleri öğrenir ve eşikleri bu örüntülere göre ayarlar. Üreticiye göre bir metrik için en az 14 günlük veri biriktikten sonra tahmine dayalı eşikler uygulanmaya başlar. İlk iki haftanın verisi bu yüzden değerlidir.
- Bakım sırasında gelen uyarılar: Planlı yeniden başlatmalar ve güncellemeler için bakım penceresi tanımlayın. OpManager’ın kesinti zamanlayıcısı, belirlenen sürede izlemeyi durdurmayı ya da izlemeye devam edip yalnızca alarmları bastırmayı sunar; tek seferlik, günlük, haftalık ya da aylık planlanabilir.
Bu haftanın hedefi, günlük uyarı sayısını ekibinizin gerçekten okuyabileceği bir düzeye indirmektir.
4. hafta: bildirim, eskalasyon ve rapor
- Bildirim profillerini tamamlayın. OpManager’da uyarılar e-posta, SMS ya da Slack gibi sohbet kanallarıyla gönderilebilir; ServiceDesk Plus, Jira ya da ServiceNow gibi sistemlerde otomatik kayıt açılabilir. Kritik uyarılar için e-postaya ek olarak anlık bir kanal seçin.
- Eskalasyon kurun. Belirli bir süre içinde ilgilenilmeyen kritik bir alarmın bir üst sorumluya ya da yedek yöneticiye iletilmesini tanımlayın. Mesai dışı sorumluluğu da bu kurallara yansıtın.
- İlk müdahaleyi otomatikleştirin. Duran bir servisin yeniden başlatılması gibi basit adımlar iş akışlarıyla otomatik yapılabilir. Bunu yalnızca etkisini iyi bildiğiniz durumlarda kullanın.
- Aylık raporu tasarlayın. Erişilebilirlik, kapasite eğilimleri ve en çok alarm üreten cihazlar. Bu rapor, bir sonraki bütçe döneminde hangi hattın ya da diskin büyütüleceği kararını veriye dayandırır.
İzleme sistemini de izleyin
Sık unutulan bir risk: İzleme sunucusunun kendisi durursa hiçbir uyarı gelmez ve sessizlik “her şey yolunda” gibi görünür. İzleme sunucusunun diskini, veritabanını ve servislerini de izleyin; bildirim kanallarının çalıştığını ayda bir test uyarısı göndererek doğrulayın. SMS ya da e-posta ağ geçidinin şifresi değiştiğinde bildirimlerin kesildiğini ancak bir arıza sırasında fark etmek istemezsiniz. İzleme sunucusunu yedekleme kapsamına almayı da unutmayın; eşikler, bağımlılıklar ve bildirim kuralları haftalarca emek verilmiş bir yapılandırmadır.
30. gün kontrol listesi
- Kritik sistem listesi yazılı ve güncel.
- Bağımlılıklar tanımlı; bir üst cihaz düştüğünde tek alarm geliyor.
- Her uyarının bir sahibi ve bir önem derecesi var.
- Günlük uyarı sayısı ekibin takip edebileceği düzeyde.
- Bakım pencereleri tanımlı.
- Kritik uyarılar için eskalasyon ve mesai dışı akışı çalışıyor.
- Yedekleme sunucusu ve servisleri izleniyor.
- Aylık rapor yönetimle paylaşılıyor.
Arayüz doluluk uyarıları geldiğinde bir sonraki soru, hattı neyin doldurduğudur. Bunun için akış verisine ihtiyaç vardır; NetFlow nedir yazımızda anlattık.
Unna ile izlemenin ilk ayı
Unna olarak izleme projelerinde kurulumu işin küçük kısmı sayarız. Önce hangi sistemlerin işiniz için kritik olduğunu ve bir sorunda kimin, hangi kanaldan haberdar olması gerektiğini dinleriz. OpManager kurulumunu, keşfi ve bağımlılıkları yaparız; ilk haftalarda gereksiz uyarıları sizinle birlikte ayıklar, eşikleri gerçek kullanımınıza göre ayarlarız. Trafik analizi için NetFlow Analyzer’ı aynı konsola ekleyebiliriz. İzleme, IT danışmanlığı hizmetimizde periyodik bakımın temel aracıdır; yedekleme altyapınızın sessizce durmasının önüne geçen de odur. İzleme sisteminizi birlikte kurmak ya da mevcut kurulumu toparlamak için bize yazın.
