Sunucu izleme ve düzenli bakım hangi riskleri erken gösterir?

Bir sunucu ping yanıtı verebilir, kullanıcı oturumu açabilir ve yine de ciddi bir probleme doğru gidiyor olabilir. Disk alanının tükenmesi, yedek işlerinin günlerdir başarısız olması, sertifikanın bitişe yaklaşması veya bir servisin sürekli yeniden başlaması basit açık-kapalı kontrolünde görünmez.

Sağlık kontrolü sunucunun ne işe yaradığına göre değişir. Dosya sunucusunda depolama ve erişim önemliyken bir uygulama sunucusunda yanıt süresi, veritabanı bağlantısı ve servis hataları daha anlamlı olabilir. Aynı alarm listesini her sisteme uygulamak bu yüzden iyi sonuç vermez.

İzleme tarafında amaç mümkün olan her metriği toplamak da değildir. İşe yarayan birkaç göstergenin normal aralığını bilmek, yüzlerce grafiğe bakmaktan daha değerlidir. Sistem normalde nasıl davranıyor sorusunun cevabı yoksa bir değerin gerçekten anormal olup olmadığını anlamak zorlaşır.

İşlemci, bellek, disk ve ağ kullanımı tek bir anlık değer olarak bakıldığında yanıltıcı olabilir. Ay sonu raporu alınırken işlemci kısa süre yükseliyorsa bu normal olabilir. Buna karşılık kullanılabilir disk alanı her gün biraz daha azalıyorsa ortada takip edilmesi gereken bir eğilim vardır.

Bu eğilim her zaman daha güçlü sunucu satın alınması gerektiğini göstermez. Gereksiz log dosyaları, büyüyen veritabanı, yanlış çalışan bir görev veya artık kullanılmayan geçici dosyalar da kapasiteyi tüketebilir. Önce neden büyüdüğünü anlamak gerekir.

Benzer şekilde bellek kullanımının yüksek olması tek başına problem değildir. Kullanıcı gecikmesi, yoğun disk kullanımı, kuyruk veya servis hatasıyla birlikte görülüyorsa daha anlamlı hale gelir. İzleme verisinin değeri metriklerin birbirine ve gerçek iş etkisine bağlanmasından gelir.

Bakım yalnızca güncelleme yüklemek değildir. İşletim sistemi ve uygulama sürümleri, yeniden başlatma ihtiyacı, yedek sonucu, sertifikalar, lisans süreleri, servis hesapları ve donanım desteği farklı zamanlarda dikkat ister.

Her güncellemeyi çıktığı dakika kurmak doğru olmayabilir. Özellikle kritik bir uygulamada üretici desteği, uyumluluk, bakım penceresi ve geri dönüş yolu düşünülür. Fakat güncellemeyi ertelemek de görünmez bir karar olmamalı. Neden ertelendiği ve ne zaman tekrar bakılacağı belli olmalı.

Bakım öncesinde mevcut yapılandırmanın veya ilgili verinin geri dönüşe uygun bir kopyası olup olmadığı da kontrol edilir. Güncelleme başarılı olsa bile servis açılmıyorsa ne yapacağımızı olay anında düşünmeye başlamak kesintiyi uzatabilir.

Bir izleme aracı yüzlerce uyarı gönderebilir. Bu uyarılar kimsenin takip etmediği bir posta kutusuna gidiyorsa teknik olarak alarm üretilir ama operasyonel olarak izleme yapılmıyordur.

Her anlamlı uyarının bir sahibi, beklenen inceleme süresi ve gerektiğinde işletmeye bildirim eşiği olmalı. Üretim veritabanındaki disk hatasıyla test sunucusundaki kısa süreli işlemci artışı aynı öncelikle ele alınmaz.

Alarm gürültüsü de ayrıca sorun yaratır. Sürekli yanlış pozitif üreten uyarılar bir süre sonra göz ardı edilir. Bu yüzden eşikler ve bildirimler zamanla gözden geçirilmeli, gerçekten karar vermeyi sağlayan sinyaller öne çıkarılmalıdır.

Yöneticiye ham CPU, RAM ve disk grafikleri göndermek çoğu zaman karar vermesine yardımcı olmaz. Daha değerli olan hangi hizmette değişiklik olduğu, bunun kullanıcıyı etkileyip etkilemediği ve bir karar gerekip gerekmediğidir.

Örneğin depolama altı ay içinde dolacak görünüyorsa tahmini tarih ve önerilen aksiyon anlamlıdır. Bir sertifika iki hafta sonra bitecekse kimin yenileyeceği önemlidir. Yedek testinde hata çıktıysa yalnızca kırmızı durum değil, neyin eksik kaldığı da bilinmelidir.

İyi rapor geçmişi de korur. Aynı uyarı aylar boyunca tekrarlanıyorsa geçici çözümler yerine kök neden için karar vermek daha kolaylaşır.