Operations Manager 2007′de en önemli olaylardan biri alert optimizasyonudur.
Bu konuda çok şey yazılabilir. Ancak bu yazımda sizlere izlemeniz gereken alert management sürecinden ufak bir kısım aktarmak istiyorum.
Geliştirdiğimiz OpsMgr çözümlerinde genelde izlenmesini tavsiye ettiğimiz Critical Alert Management süreci aşağıdaki gibidir:
A: Alert belirli bir event log’dan dolayı üretiliyordur. Ancak alert’in üretildiği event log datası sizin için birşey ifade etmiyor olabilir. Bu durumda ilgili alert’i disable edebilirsiniz veya kurumunuzun ihtiyacına göre özelleştirebilirsiniz.
B: Alert üretilmesi için belirli bir eşik değeri vardır. Bu eşik değerleri belirlenirken ya Microsoft, müşterilerinin geneli için bir “best practice” değer düşünmüştür veya ortamınızı bir süre dinleyip otomatik olarak size uygun eşik değeri oluşturabilen baseline monitor tipini uygun görmüştür. Bu tip alert’lere bir örnek hemen hemen tüm müşterilerde optimize etmemiz gereken DNS Management Pack’indeki “DNS Resolution Time Alert” değeridir. Bu değer Microsoft tarafından 1sn olarak belirlense de birçok DNS sunucusunda 2-2,5 saniye civarındadır. Bununla birlikte eşik değerlerini değiştirirken kafanıza göre değil, yine OpsMgr’den çıkan raporlara göre yapmalısınız. Örneğin, DNS Resolution Time Alert değerinin sizin için ortalama ne olduğunu incelemeniz için “Microsoft Windows DNS Server -> Microsoft Windows DNS 2003 -> Performance -> Local Resolution Time” performans counter’ından faydalanmak akıllıca olacaktır. İlgili performans view’ler, raporlar ile size uygun değeri bulup, monitor / rule’u optimize etmelisiniz.
C: Çok sık rastladığımız bir dğer optimize edilmesi gereken alert tipi ise kapasite ile ilgili alert’lerdir. Bu alertlerin de durumu B tipi alertlerle benzerdir. Örneğin, Windows Server (BaseOS) Management Pack’inde disk kapasitesi %10′un altına düştüğünde warning üretir. Örneğin, 8TB’lık bir diskin %10 boş alanı olması her durumda warning olmayabilir. Veya bazı ortamlar için processor interrupt değeri %10 değil %15 olarak set edilebilir.
D: En sık rastlanan optimizasyon gereksinimlerinden biri ise gelen alert’in kritiklik değeridir. Birçok kurum için birçok alert kritik olarak açılabilir, ancak warning veya information olabilir. Örneğin SQL autoshrink / autoclose flag’lar sizin için critical değil warning olabilir. Bu durumda alert’lerin seviyelerini override ederek değiştirmelisiniz.
Operations Manager 2007 projeleri tamamlandıktan sonra, üretilen kritik hataların gerçekten sizin için kritik bir hata anlamını taşıyacak şekilde optimize edilmesi orta/orta-büyük ölçekli bir servis ağacı modelinde 1-6 ay arası sürecektir. Bu süreci kısaltmanın en doğru yolu alert optimizasyon yöntemini doğru belirlemektir. Eğer doğru danışmanlık firması ile çalışırsanız OpsMgr projenizin biryerlerinde Alert optimizasyonu yöntemleri için doğru tecrübeyi de kurumunuza aktaracaktır.
Ortam optimize hale geldikten bir sonraki adımınız ise Operations Manager 2007 Service Level Tracking olarak bilinen servis seviyeleerini dashboard ortamından (Sharepoint) izlemek olacaktır. Bu konuda yakın zamanda bir makale yazacağım.