Ekim ayı Operations Manager ile ilgili yenilikler aşağıdaki gibidir:

• Güncellenen Yönetim Paketleri: Windows Server Operating System Management Pack, Active Directory Management Pack, ConfigMgr 2007 Management Pack
• OpsMgr 2007 R2 artık SQL 2008 R2 SP1′i destekliyor.
• Tim McFadden MP dosyalarını XML’e çevirmek için yeni ve çok kullanışlı bir araç yazdı.
• SQL Server PDW appliance cihazlarını monitor etmek için Microsoft SQL Server 2008 R2 Parallel Data Warehouse Appliance Management Pack yayınlandı.

SCOM 2012′de birçok yeni özellik geldi, her tarafında birkaç değişiklik veya en azından rötuş bulunmakta. Ancak ne yazık ki SCOM 2012′de ACS konusunda herhangi bir geliştirme veya yenilik gelmemekte.

Bunun sebebinin, Microsoft’un GRC tarafının artık apayrı bir ekip tarafından geliştirilmesi ve bu ekibin de BT ortamında denetleme süreçlerini Service Manager üzerinde geliştirdiğini, zaman içinde bu özelliğin tamamen SCOM’dan SCSM (Service Manager) ‘a alınacağı konusunda dedikodular var.

SCOM 2007 mimarinizi SCOM 2012′ye yükseltmeden önce tüm donanım ve yazılım ön koşullarını karşılamanız gerekmektedir. SCOM 2012′nin desteklenen konfigürasyonları için technet.microsoft.com/library/hh205990.aspx adresindeki makaleden faydalanabilirsiniz.

Mimarisinizi Operations Manager 2012′ye yükseltirken takip etmeniz gereken teknik dokümana technet.microsoft.com/en-us/library/hh205974.aspx adresinden erişilebilir. Aşağıdaki diyagram mimarinizi Operations Manager 2012′ye yükseltirken takip edebileceğiniz üst seviye bir iş akışı diyagramıdır.

Müşterilerimizde birçok zaman ürettiği bilgi ve hataları Windows Event Log’una yazmak yerine sistem üzerinde oluşturduğu bir dosyaya yazan bir BT bileşeni ile karşılaşıyoruz. Bu tip durumlar için Operations Manager’ın Log Dosyası’nın içeriğini okuyup, sizin verdiğiniz parametrelere göre uyarı veya hata üretme gibi bir özelliği var, bu özelliği de eminim birçoğunuz birçok defa kullanmıştır.

Bununla birlikte forumlarda bu konuda oldukça soru gelmesi sebebiyle bu konudaki püf noktaları yayınlamak istedim.

Öncelikle aşağıdaki noktalara dikkat etmekte fayda var:

Log dosyasını temizlemeyin

Operations Manager log dosyanızdaki “en son kontrol edilen satır” ı hatırlayacaktır. Örneğin, en son 120 numaralı satırda kaldıysa, bir sonraki kontrol zamanında 101. satırdan devam eder. Eğer log dosyasını silerseniz log dosyası 1. satırdan başlayacaktır ve SCOM, log dosyanız 120. satıra gelene kadar okumayacaktır.

Operations Manager will remember the last checked line within your log file. So in case that was in line 100, SCOM will start reading in line 101 the next time the workflow runs. If you decide to clear the log file and start filling it from line 1, SCOM will not proceed until line 101 is reached

Aynı log dosyasına yazıyorsa

Yeni log dosyası oluşturmuyorsa (sürekli aynı log dosyasına yazıyorsa), dosyanın boyutuna dikkat edin. Bunun için dosya boyutu belirli bir rakama ulaştığında SCOM’a uyarı oluşturtabilirsiniz.

Yeni dosya oluşturuyorsa

Belirli bir zamanda (günlük, haftalık vb) veya belirli bir dosya boyutuna ulaşıldığında otomatik olarak yeni dosya oluşturuyorsa (ki genelde bu tercih edilir) gerçek dosya isminin her zaman değişmek zorunda olduğunu unutmayın. Örneğin, güncel log dosyasının ismi uygulama_guncel.log iken eski log dosyalarını uygulama_<tarih>_<zaman>.log ya da benzer bir şekilde arşivliyor olabilir. Yeni oluşturulan dosyanın “Oluşturulma zamanı” etiketi eski dosyadan daha yeni olduğu sürece SCOM için problem olmaz, yeni dosyayı algılar ve devam eder.

Ancak, NTFS’te bir dosyayı sildiğinizde ve aynı dakika içinde aynı isimde yeni bir dosya oluşturduğunuzda yeni dosyanın “oluşturulma zamanı” eskisi ile aynı olacaktır ve SCOM da bu yeni dosyaya sanki içi temizlenmiş bir dosya olarak yaklaşacak ve birinci maddedeki (Log dosyasını temizlemeyin) problem ile karşılaşacaksınız.

Bu senaryoyu kolaylıkla test edebilirsiniz:

1. Bilgisayarınızda “dosya.txt” isminde bir dosya oluşturun.
2. Oluşturulma zamanına bakın.
3. En azından bir dakika bekleyin ve “şu anki zaman” ile “oluşturulma zamanını” aklınızda tutun.
4. Dosyayı silin.
5. Dosyayı sildikten sonraki 1 dakika içinde aynı isimde bir dosya oluşturun.
6. Dosyaının “oluşturulma” zamanına baktığınızda bir önce oluşturduğunuz dosya ile saniyesine kadar aynı olduğunu göreceksiniz.

Farklı bir senaryo olarak:

1. Bilgisayarınızda “dosya.txt” isminde bir dosya oluşturun.
2. Oluşturulma zamanına bakın.
3. En azından bir dakika bekleyin ve “şu anki zaman” ile “oluşturulma zamanını” aklınızda tutun.
4. Dosyayı silin.
5. Bir dakikadan daha uzun bir süre bekleyin.
5. Aynı isimde bir dosya oluşturun.
6. Dosyaının “oluşturulma” zamanına baktığınızda bir önce oluşturduğunuz dosya ile aynı olmadığın, güncel tarihi aldığını göreceksiniz.

Bunun sebebi, NTFS’in metadata’sının dakikada bir güncellenmesidir.

İlgili log dosyalarını oluşturan yazılımlar / donanımlar ise genelde eski log dosyasını arşivledikten sonra aynı dakika içinde yeni dosya oluşturular! SCOM ise bu dosyalara sanki dosyanın içi silinmiş gibi davranır.

Bu konuda bir geçiçi çözüm ararsanız: güncel log dosyasında da (mümkünse) tarih ve zaman kullanmak (jenerik bir isim kullanmamak) ve log dosyasını izlerken direk dosya ismi vermek yerine değişken kullanmak. Örneğin, log dosyanız uygulama_<tarih>_<zaman>.log ise iş akışını “uygulama_*_*.log” isimli dosyayı izlemek için oluşturabilirsiniz.

SCOM 2012 kurmadan önce göz önünde bulundurmanız önerilen birkaç önemli nokta:

• RMS (Root Manageme Server) Rolü artık yok. SCOM 2012′de tüm Yönetim Sunucuları (Management Servers) hemen hemen benzer özelliklere sahiptirler, eşittirler.  Tıpkı NT4 domainlerinden Windows 2000 ve sonrası forest’lara geçiş sırasında geriye dönük uyumluluk için PDC Emülatörü rolü oluşturulduysa buna benzer olarak SCOM 2012 için de PDC Emülatörü rolü oluşturulmuştur. RMS Emülatörü çalışmak için RMS’e ihtiyaç duyan eski yönetim paketlerinin SCOM 2012 ortamında da çalışmasına olanak tanır. Bu rol PowerShell kullanılarak taşınabilir veya yönetilebilir (set-scomrmsemulator , get-scomrmsemulator)
• Kaynak Havuzları (Resource Pools). Ağ cihazları ve Windows olmayan sunucuların hata durumunda failover’ı için artık kaynak havuzlarını kullanabiliriz. Burada aklınızda tutmanız gereken nokta Windows ajanları failover için kaynak havuzlarını kullanmazlar ve failover konusunda SCOM 2007′dek ile aynı davranışı sergilerler. Aynı zamanda bir diğer önemli nokta da, kaynak havuzlarının sadece Health Service’in fonksiyonu için geçerli olduğu SDK fonksiyonalitesi için geçerli olmadığıdır. Dolayısıyla kaynak havuzlarını OpsMgr konnektörleri veya raporlama için kullanamazsınız.
• Operations Manager Yönetim Grubu. Artık kurulum sırasında veya farklı bir noktada Operations Manager Yönetim Grubu sorulmamaktadır. Bunun yerine, kurulum sihirbazı otomatik olarak yerel sunucudaki “Administrators” grubunu Operations  Manager Administrators rolüne atamaktadır. Operations Manager kurulumunu, kuracağınız ilk yönetim sunucusunda Administrator yetkisine sahip bir kullanıcı ile çalıştırmanız gerekmektedir, bu sayede kurulum tamamlandığında operasyon konsolunu kullanabilirsiniz. Bu konuda doğru yaklaşım her yönetim sunucusunda global ve lokal seviyede bir OpsMgr Admins güvenlik grubu oluşturmak ve ilgili kullanıcıları global gruba ekleyip, gloabl grubu da lokal gruba eklemek, devamında ise operasyon konsolundan lokal gruba OpsMgr Admins rolü atamaktır.
• Raporlama. Raporlama artık ayrı bir kurulum değil, başlangıç kurulum sürecinin bir parçasıdır. Dolayısıyla, artık SCOM kurmak için Reporting’i de aynı zamanda kurmak zorundasınız.
• Full Text Search. Bu SQL Servisi artık birçok System Center ürününde standart gereksinim olarak istenilmektedir.

İlgili makale için support.microsoft.com/kb/2591380 adresini ziyaret edebilirsiniz.

İlgili haber için: blogs.technet.com/b/momteam/archive/2011/08/10/scom-2007-r2-and-sp1-now-supports-sql-server-2005-sp4.aspx

Değişiklikleri, düzeltilen alanları ve yönergeleri içeren makale:

support.microsoft.com/kb/2495674

Aşağıdaki adresten indirebilirsiniz:

www.microsoft.com/download/en/details.aspx?id=26938

OpsMgr 2007 R2 tümleşik güncellemelerinin (Cumulative Update) tamamının listelenebileceği adres:

support.microsoft.com/kb/2453149

——–

• Restarts of non-Operations Manager services when the agent is updated is resolved.
• UI hang caused by SDK locking.
• Web console is timing out while opening the left navigation tree.
• Reports - Drill-through fails due to rsParameterTypeMismatch in the EnterpriseManagementChartControl.
• Reports - Edit Schedule button is disabled with SQL Server 2008 R2.
• Reports - Scheduled Reports view for Windows Server 2003 and SQL SRS 2005 SP3 CU9 - returns System.IndexOutOfRangeException: Index was outside the bounds of the array.
• ACS - Event log message is truncated or corrupted in SCDW.
• ACS Filter fails for certain wildcard queries.
• ACS - Updated ACS reports
• Workflows - TCP Port Probe incorrectly reports negative ping latency.
• Workflows - MissingEvent Manual Reset Monitor does not work as expected.
• Workflows - Signed MPs cannot be imported when new attributes are added to existing classes.

Cumulative Update 5 for Operations Manager 2007 R2 resolves the following issues:

• Performance data for LVM managed partitions is not available
• Process monitor does not retain name if run via symbolic link
• AIX with large number of processes crashes with bad alloc

Cross Platform Cumulative Update 5 for Operations Manager 2007 R2 adds the following features:

• Support for Red Hat 6

Uzun süredir test ettiğimiz ve beklenen Operations Manager 2012 halka açık beta sürümü yayınlandı.

İndirmek için: www.microsoft.com/download/en/details.aspx?id=26804

Destek ve tartışma grupları için: social.technet.microsoft.com/Forums/en-US/category/systemcenteroperationsmanager

Operations Manager ilk çıktığında temel seviyede Microsoft ürünlerini izlemekteydi. 2007 versiyonu ile beraber Operations Manager, BT Hizmet Yönetimi ailesinin bir parçası olmaya aday, veri merkezinizdeki işinizi etkileyen tüm BT bileşenlerinin sağlığını birçok perspektiften izlemeye aday bir çözüm olarak piyasaya çıktı ve birçok büyük ölçekli kurumda kabul gördü.

2007 versiyonunda ağ izleme, uygulama izleme gibi birçok özellik vardı, R2 versiyonu ile Operations Manager artık sınırlarını net olarak Microsoft dünyasından büyük ölçekli bir kurumun veri merkezindeki tüm BT bileşenlerine doğru genişletti.

Bu sırada birçok kaliteli Microsoft İş Ortağı çok kaliteli yönetim paketleri yayınlayarak bu sınırları Oracle, IBM, HP, SAP gibi farklı üreticilerin ürünlerine doğru genişlettiler. Bu yönetim paketlerinin birçoğu o kadar kaliteliydi ki, ilgili üreticinin kendi uygulamasını izlesin diye ürettiği kendi yazılımından daha başarılı şekilde izlemeyi başardılar.

Operations Manager 2007 R2 ile beraber Microsoft’un daha da iyileştirme yapması gereken noktalar net olarak kendini belirli etmeye başladı ve Microsoft, Operations Manager 2012 ile beraber bu alanlardaki açıkları kapatmayı hedefleri.

Bu alanlardan en önemlilerinden biri ağ izleme idi. Microsoft SCOM 2012 ile beraber bu konuda birçok yenilik getirdi. Bir diğer alan ise .NET uygulama izleme konusundaydı. Bu noktada Microsoft, AVIcode’u satın alarak SCOM 2012′de ürünün içine dahil etme kararı aldı.

AVIcode

AVIcode, Microsoft satın almadan önce de Gartner tarafından .NET Uygulama İzleme konusunda dünya üzerindeki en başarılı yazılımdı. Oldukça detaylı ve kapasiteli olan yazılımın yaptığı iş “Çalışmak için sunum katmanı, veri tabanı katmanı, web sunucusu katmanı, ağ katmanı gibi birçok katmanın bir arada ve başarı ile çalışması gereken uygulamalarda hata anında hatanın izole edilmesi ve çözülmesi” olarak özetlenebilir. AVIcode’un en büyük avantajlarından biri, geliştirmiş olduğunuz .NET uygulamanızın son kullanıcı deneyimini kolaylıkla yakalayıp, son kullanıcıdan veri tabanına gidene kadar olan yolculuktaki tüm uğrak noktalarının performansını ve çıktılarını ayrı ayrı değerlendirip analiz edebilme yeteneğidir.

AVIcode, sunucu/bileşenleri, son kullanıcı , transaction gibi farklı perspektiflerden uygulamalarınızı izlerken, uygulamaların farklı katmanlarda çalışan bileşenlerin birbirlerine olan bağımlılıklarını da keşfedebilmekte, dolayısıyla uygulamanızı uçtan uca bir bütün olarak izleyebilmektedir.

Production ortamında uygulamalarınızı kod seviyesi hatalar, performans darboğazları, güvenlik ve bağlantı hataları gibi birçok perspektiften izleyebilir ve detaylandırılması çok kolay olan görsel grafik ve raporlarları kullanımınıza sunar. Production ortamlarında rahatlıkla kullanılabilir, çünkü AVIcode herhangi bir kod değişikliğine veya kodun yeniden derlenmesine ihtiyaç duymaz, aynı zamanda göz ardı edilebilir bir işlemci yükü ile çalışır.

AVIcode aynı zamanda Biztalk ve SharePoint çözümleri ile de entegre çalışabilirken Visual Studio Team System ile entegre çalışarak yazılımcıların en önemli araçları arasında yerini almaktadır.

Exchange Server 2010 Management Pack ve Korelasyon Motoru ile ilgili anlaşılması gereken önemli bir başka nokta da Korelasyon Motorunun var oluşunun Exchange Management Pack’i diğer Management Pack’lerden ayrılmasını sağlayan etkileridir.

Exchange Server 2010′da Korelasyon Motoru’nun var olması bu yönetim paketini diğer yönetim paketlerinden aşağıdaki noktalarda farklılaştırmaktadır:

• Exchange Server 2010 yönetim paketi motitörleri durum değişikliği uyarılarında (State Change Events) otomatik olarak uyarı göndermeye ayarlanmamıştır. Bunun sebebi, uyarının gönderilip gönderilmeyeceğine Korelasyon Motoru’nun karar vermesidir.
• Korelasyon Motoru servisi durdurulursa, Exchange Server 2010 Yönetim Paketi Operations Manager üzerinden Exchange ortamınızın sağlığı ile ilgili uyarı veremez. Bunun sebebi, normalde tüm monitör’lerin “otomatik uyarı gönder” modunun kapalı olması, uyarıyı Korelasyon Motoru’nun vermesinden dolayıdır. Korelasyon Motoru durdurulursa Korelasyon Motorunun çalışmadığına dair genel bir uyarı gelir.

Korelasyon Motoru’nun var olması, aşağıdaki noktalarda değişiklik yaratmamaktadır.

• Override’lar normal şekilde çalışmaktadır, diğer yönetim paketlerinde yaptığınız gibi monitörler ile ilgili parametrik değerleri değiştirebilir veya monitörleri devre dışı bırakabilirsiniz (disable).
• Bakım (maintenance) modunda olan monitörler Korelasyon Motoru tarafından göz ardı edilirler. Bakım modunda olan monitörler durum değişikliği uyarılarını oluşturmadıkları için Korelasyon Motoru’nun değerlendirmesine dahil olmazlar.
• Exchange Server 2010 Yönetim Paketine Per-monitor uyarı kuralları eklenmiştir. Uyarı kuralları ilgili monitörler için uyarı üretmese bile, per-monitor uyarı kuraları operatörlerin ilgili uyarı için kuruma özel notları “Company Knowledge” alanına girmesine izin verir.
• Diğer yönetim paketleri Korelasyon Motoru’nun varlığından etkilenmezler.

Sonuç olarak, akılda  tutulması gereken önemli bir nokta, uyarının algılanmasından konsola yansıtılmasına kadar olan süreçte, korelasyon tarafından müdahale edilerek iyileştirilen tek adımın “uyarı oluşturmak için durum değişikliğini izle” adımı olduğudur.

SCOM 2012 beta versiyonu ile beraber entegre edilmiş AVIcode’u da test etmeye başlayabilirsiniz.

AVIcode’un SCOM 2012 ile birleştirilmesi sonucu, eskiden AVIcode’da alışık olduğumuz detaylı, ince ayarlar gidip yerine daha az konfigürasyon seçeneği sunan, ancak bir o kadar da kullanımı kolaylaşmış bir ürün gelmiş.

Bu yeni AVIcode ile beraber, beta versiyonundaki ilk izlenimler aşağıdaki gibidir:

Windows uygulamaları

Beta versiyonunda ilk göze çarpan, eskiden AVIcode ile yapabildiğimiz Windows servis ve executable izleme özelliğinin olmadığı, sadece web uygulamalarının (+web servisleri) izlemesinin desteklendiğidir. Elbette bu özellik entegre edilmediği taktirde gerçek hayattaki birçok senaryonun hayata geçirilemeyeceği, masa üstü uygulamalarının, windows servisleri ve IIS üzerinden sunulmayan WCF’lerin izlenmesinin mümkün olamayacağı gerçeği de önemli bir nokta.

Aynı şablona birden fazla uygulama eklemek

Aynı şablona birden fazla uygulama ekleyebilirsiniz, bu sayede artık birçok uygulamayı bir anda izlemeye başlamak çok daha kolay.

Sunucu konfigürasyonu

AVIcode’un en can alıcı özelliklerinden biri olan sunucu tarafında yapılankonfigürasyon sayesinde fast SQL çağrıları, uygulamaların internal çağrıları gibi birçok detaylı nokta izlenebilmekteydi. Var olan durumda tek yapılabilen neyin izlenmesi ve neyin izlenmemesi gerektiğini belirtmekten ibaret. Bu, yönetim kolaylığı sağlarken uygulama geliştiriciler için .NET izleme özelliğini çok zayıf hale getirmekte.

Standalone versiyon

SCOM 2012 ile beraber AVIcode’un tek başına kurulabilen versiyonunu öldüreceklerini biliyorduk. .NET uygulama izleme özelliğinin de diğer tüm özellikler gibi sadece operasyon konsolundan yönetilmesi, yönetim ve operasyon açısından iyi bir yaklaşım olsa da, yazılımcıların birçoğunun Operations Manager bilmediğini (ve bilmek de istemeyeceğini) var saydığımızda büyük bir dez avantaj olabilir.

Kurulum

Microsoft’un en başarılı yaptığı işlerden biri olan “kolay ve sorunsuz kurulum” burada da kendini gösteriyor. AVIcode’un eski kurulumuna kadar çok daha kolay bir kurulum süreci bulunmakta.

• .NET izleme ajanı artık SCOM’un bir parçası olarak yaygınlaştırılmakta, ek bir konfigürasyon gerektirmemekte.
• AVIcode Advisor bileşeni SCOM Web Konsolu kurulumu ile beraber kurulmakta. Artık “App Advisor” olarak alınmakta ama aslında alıştığımız AVIcode Advisor uygulaması.
• İstemci tarafı izleme .NET uygulama izleme ile entegre edilmiş durumda, herhangi bir ek yönetim paketi veya ek kurulum gerektirmemekte.

Veri Analizi

Alışık olduğumuz AVIcode SEViewer uygulaması gizlenmiş durumda. Ancak, halen (eskiden olduğu gibi) SCOM alert context’e gidip “click here” yazan yere tıklayıp “App Diagnostics” web uygulamasını çalıştırabiliyoruz ve SEViewer’da eskiden gördüğümüz detay penceresinin aynısı açılıyor, ancak bu pencere SEViewer’dan geriye kalan tek fonksiyonalite; App Diagnostics ara yüzünde alışık olduğumuz gruplama veya filtreleme gibi SEViewer özellikleri artık bulunmamakta.

Veri Tabanı

.NET Monitoring için ayrı bir veri tabanı yok (ki bu güzel birşey). Tüm veri, Operations Manager veri tabanına entegre edilmiş durumda. .NET monitoring ile ilgili eklenen verilerin bakımının veya veri tabanı seviyesindeki ince ayarlarının nasıl yapılacağı ile ilgili bir bilgi ise henüz yayınlanmış durumda değil.

Bu özelliklerin bir çoğu RTM versiyona eklenebilir, değişebilir. Ancak şu anda ilk izlenimler bunlar.

Heterojen ortamlarda Opalis çok kullanışlı bir çözüm olarak uygulanmakta. Özellikle Microsoft çözümleri ile beraber SCOM’un UNIX/Linux monitoring özelliğini de kullananlar Opalis kullanmak istediklerinde birçok senaryoda UNIX/Linux sunucular ile ilgili bazı bilgilere göre (disk alanının dolu olması, işlemci performansı, boş bellek vs) otomatik iş akışları oluşturmak veya var olan iş akışlarında UNIX/Linux ile ilgili bazı bilgileri sorgulamak zorunda kalabiliyorlar.

Opalis’i bu tip iş akışları için de kullanabilirsiniz. Nasıl yapılabileceği ile ilgili blogs.technet.com/b/opalis/archive/2010/11/11/using-opalis-to-get-info-from-the-scx-cross-platform-agent.aspx adresinde detaylı bilgi mevcut.

Aklınıza takılan ya da uygularken sorun yaşadığınız taktirde benimle iletişime geçebilirsiniz.

Endüstrinin SOA tabanlı distributed application’lara doğru hızla ilerlemesi ile SCOM’daki Synthetic Application Monitoring özelliği daha da önemli hale geliyor. SCOM’un bu özelliği sayesinde “Web Site’ınız veya Web Servisiniz neden LOB uygulamanızın yavaş çalışmasına sebep oluyor?” sorusuna cevap vermek için detaylı ölçümler ve incelemelerde bulunbilirsiniz. Kullanıcıların bir LOB uygulaması ile etkileşimini birebir taklit ederek son kullanıcının benzer deneyim kalitesini yaşayıp yaşamadığını sürekli olarak kontrol edebilirsiniz.

Synthetic monitoring için takip etmenizde faydalı olabilecek tavsiyeleri aşağıdaki gibi özetledik:

• Yazılım geleştiricilerden ilgili uygulama ile ilgili performans eşik değerlerini alın ve operasyonel sonuçlar sağlayın.
• Kurumunuz için en önemli iş sorgularını içeren synthetic script’ler hazırlayın
• Kullanıcılarınızın bulunduğu tüm WAN bölgelerinden uygulamanızı düzenli olarak sorgulayın
• Synthetic sorgular ile oluşturduğunuz yükün sonuçlarını uygulamanızın performans sonuçlarını raporlamak için kullanın

Exchange 2010 Yönetim paketi ile birlikte correlation engine (korelasyon motoru) geldi. Korelasyon Motoru aslında Operations Manager SDK’sını kullanan bir Windows Servisidir ve temel görevi sağlık modelini değerlendirip durum değişikliği olaylarını işler. Sağlık modelini hafızada saklayarak ve sağlık durumu değişimi olaylarını işleyerek Korelasyon Motoru sistemin durumuna göre uyarı (alert) oluşturup oluşturmamaya karar verir.

Bir problem oluşması durumunda birçok Operations monitor’ü durum değiştirir (kırmızı-yeşil-sarı) ve bu durum değişiklikleri Root Management Server (RMS)’a yönlendirilir. RMS tarafından alınan uyarılar daha sonra Korelasyon Motoru’na gönderilir ve Korelasyon Motoru gerekli durumlarda RMS SDK’sını kullanarak uyarıyı işler ve uyarı konsolda gözükür. Yani aslında kısaca, Korelasyon Motoru, monitörlerin ürettiği hatalar ile konsol arasında durarak konsola yansıyan hataların niteliğini ve kalitesini kontrol eder.

Korelasyon Etkenleri

Korelasyon Motoru tarafından gerçekleştirilen görevler birçok etkeni baz alır.

Monitör Durum Değişikliği Olayları. Monitörler event log mesajı, performans sayaç eşik değerleri veya PowerShell task çıktıları gibi birçok noktadan bilgi toplarlar ve bir problem oluştuğunda veya çözüldüğünde (kırmızı dan yeşile veya yeşilden kırmızıya) veya ajanlar erişilemez olduğunda veya maintenance moda alındığında bu değişiklikleri durum değişikliği olayı olarak kayıt altına alırlar.

Tipik olarak, yeşilden kırmızıya durum değişikliği gerçekleştiğinde uyarı (alert) kuralları devreye girerler ve uyarı oluştururlar. Exchange Server 2010 Yönetim Paketi’nde, sürecin bu şekilde işlemediğini fark edersiniz, Exchange Server Korelasyon Motoru sayesinde bir sağlık durumu değişimi sonucunda otomatik olarak uyarılar üretilmez, Korelasyon Motoru duruma göre konsola yansıtılması gereken en uygun uyarıya karar verir.

Sağlık Modeli. Exchange Server 2010 sağlık modeli tarafından Operations Manager’a import edilen class hiyerarşisi çok büyük ve karmaşıktır. Class hiyerarşisi tüm sistemdeki bileşenlerin birbirine olan bağımlılıklarını tanımlayan class ilişkilerini içerir. Bu bileşen bağımlılıklarının tanımlanması ile beraber, Exchange Server 2010 yönetim paketi Exchange organizasyonunuzun sağlığını daha iyi yorumlar ve anlar. Örnek olarak, eğer Exchange Server 2010 Yönetim Paketi, Active Directory’nin temel fonksiyonlarının offline olduğunu fark ederse, aynı zamanda Exchange mesajlaşma mimarisinin de tam işlevli olarak çalışmadığını raporlayacaktır.

Zamanlama. Korelasyon Motoru 90 saniyelik aralıklarla çalışır. Birden fazla monitör için durum değişikliği olayları aynı anda gelirse, Korelasyon Motoru, ITIL’daki problem yönetimi sürecine benzer bir yaklaşım ile, gelen hatalarla ilgili farklı bir potansiyel hata gelecek mi diye bekler ve kök sebep analizi gerçekleştirir.

Korelasyon Algoritması

Korelasyon Motoru Sürecinin Gözden Geçirilmesi

1. İlk olarak Operations Manager SDK’sına bağlanarak sağlık modeli hiyerarşisi ve örnek (instance) sağlık durumunu alır (bu adım sadece servis başlangıcında veya oluşan hatalar bu gerektirdiğinde çalıştırılır)

2. Exchange Management pack’teki ilgili objeler ile ilgili sağlık değişim olayları ile ilgili Operations Manager sorgulanır.

3. Eğer yeni NSI (Non Service Impacting - Hizmeti Etkilemeyen) durum değişiklikleri ortaya çıkarılırsa bunlarla ilgili uyarı (alert) üretilir.

4. Anahtar Sağlık Göstergeç (Key Health Indicator - KHI) monitörleri değerlendirilir ve birbiri ile alakalı kırmızı durumdaki KHI zincirleri izole edilir. Bu zincirler bir objenin sağlıklı çalışması için bağımlı olduğu diğer varlıklarda hata olduğunu ve bu hatanın diğer bağımlı objeleri de etkilediğini gösterir. Bu bağımlılıkların analiz edilip anlaşılması en önemli adımlardan biridir.

5. KHI zincirindeki birbirini tetikleyen birçok hata arasından kök sebep bulunur ve bu kök sebeple ilgili hatalar konsola gönderilir.

6. 90 saniye beklenir ve yukarıdaki 2. adımdan itibaren süreç tekrar çalıştırılır.

Korelasyon Motoru Sürecini İlgilendiren Ek Bilgiler

• Eğer KHI zinciri hem “hata (error - kırmızı)” hem uyarı (warning - sarı)” monitörleri içeriyorsa, uyarı (alert), kök sebep monitörünün class’ından bağımsız olarak “hata” olarak gönderilir. Örnek olarak, eğer üst katmanda çalışan bir süreç kritik hata durumunu yakalamak için gerekli bir hata monitörü tanımladıysa ve bu hata monitörü bağımlılıklar göz önüne alındığında bir uyarı (warning) monitörü ile korale edildiyse, uyarı, bağımlılığı olan warning monitörü için üretilir, ancak uyarı yerine hata olarak gösterilir.
• Tüm class ilişkileri uyarı korelasyonu için kullanılmaz. Korelasyon Motoru tarafından kullanılan spesifik ilişkilendirme bilgiler için Ek-Class Hiyerarşisi dokümanından faydalanabilirsiniz.
• Korelasyon Motoru tarafından konsola gönderilen final uyarının Alert Context alanında KHI zinciri (adli monitörler de dahil olmak üzere) incelenebilir. Bu sayede ilgili uyarı için korale edilen monitörler incelenebilir ve bağımlı olan monitörlerden sağlanan uyarılar incelenerek spesifik hatalar ayıklanabilir.
• Sağlık modeli değerlendirilirken Maintenance (Bakım) modunda olan monitörler göz ardı edili