SCOM ile Kurumsal Windows İzleme Yapılandırması

Yazar:komut.io ekibi Windows Sunucu İzleme ve Performans Yönetimi
0 Yorum

Kurumsal ortamlarda Windows sunucularını izlemek, bir noktadan sonra elle takip edilemez hale gelir. Onlarca, yüzlerce sunucu söz konusu olduğunda basit script’ler ve gösterge panoları yetersiz kalır. İşte tam bu noktada System Center Operations Manager (SCOM) devreye girer. Yıllar içinde birçok kurumda SCOM kurulumu ve yapılandırması yaptım; bazıları neredeyse sıfırdan, bazıları miras alınan ve kimsenin tam olarak anlamadığı sistemler. Bu yazıda, gerçek bir kurumsal ortamda SCOM’u nasıl anlamlı biçimde yapılandırabileceğinizi aktarmaya çalışacağım.

SCOM Nedir ve Ne Zaman Kullanılmalı

SCOM, Microsoft’un System Center ailesinin izleme bileşenidir. Temel olarak agent tabanlı çalışır; yönetilen her sunucuya bir agent kurulur, bu agent merkezi yönetim sunucusuna (Management Server) veri gönderir. Ağ cihazları ve agent kurulamayan sistemler için agentless mod da mevcut ama deneyimlerime göre agentless modun sınırlılıkları çok çabuk gün yüzüne çıkıyor.

SCOM’u ne zaman tercih etmelisiniz? Eğer tamamen Windows ağırlıklı bir altyapınız varsa, Active Directory, Exchange, SQL Server, IIS gibi Microsoft ürünlerini yönetiyorsanız ve bunlar için hazır Management Pack’lerden faydalanmak istiyorsanız SCOM mantıklı bir seçim. Karma ortamlarda ise Prometheus/Grafana gibi açık kaynak araçlarla birlikte kullanmak daha sağlıklı olabiliyor.

Management Pack Kavramı ve Önemi

SCOM’da her şey Management Pack (MP) etrafında döner. MP’ler, belirli bir uygulama veya servisi nasıl izleyeceğinizi, hangi metrikleri toplayacağınızı ve hangi koşullarda alarm üreteceğinizi tanımlayan paketlerdir. Microsoft’un SQL Server, Active Directory, Exchange ve IIS için yayımladığı resmi MP’ler gerçekten kapsamlıdır.

Yeni bir SCOM kurulumunda yapılan en yaygın hata, MP’leri default ayarlarıyla içe aktarmak ve her şeyin çalışmasını beklemektir. Bu yaklaşım genellikle alarm tufanıyla sonuçlanır ve ekipler zamanla alarmları görmezden gelmeye başlar. Alarm yorgunluğu, izleme sistemlerini işlevsiz kılan en büyük düşmandır.

Kurulum Sonrası Temel Yapılandırma

SCOM kurulumunu tamamladıktan sonra doğrudan agent deploy etmeye atlamak yerine birkaç temel adımı sıraya koymanızı öneririm.

Operations Manager veritabanı boyutunu yapılandırın:

# Operations Manager DB için retention süresini ayarlama
# SCOM Shell üzerinden çalıştırın
$mg = Get-SCOMManagementGroup
Set-SCOMDatabaseGroomingSetting `
    -AlertDaysToKeep 30 `
    -AvailabilityHistoryDaysToKeep 7 `
    -EventDaysToKeep 7 `
    -JobStatusDaysToKeep 7 `
    -MaintenanceModeHistoryDaysToKeep 14 `
    -MonitoringJobDaysToKeep 7 `
    -PerformanceDataDaysToKeep 14 `
    -StateChangeEventDaysToKeep 7

Bu ayarları atlarsanız Operations Manager veritabanınız hızla şişer. 500 sunuculu bir ortamda birkaç ay içinde yüzlerce gigabayt’a ulaşabilir.

Run As hesaplarını doğru yapılandırın:

SCOM’un en çok sorun çıkaran konularından biri hesap yönetimidir. Her servis için ayrı Run As Account tanımlamak, uzun vadede çok daha yönetilebilir bir yapı sağlar.

# SQL Server izleme için Run As Account oluşturma
$credential = Get-Credential -Message "SQL Monitoring Account"
$runAsAccount = Add-SCOMRunAsAccount `
    -Windows `
    -Name "SQL Monitoring Account" `
    -Description "SQL Server izleme için kullanılan hesap" `
    -Credential $credential

# Run As Profile'a hesabı atama
$profile = Get-SCOMRunAsProfile -DisplayName "SQL Server Monitoring Account"
Set-SCOMRunAsProfile -Profile $profile -Account $runAsAccount

Agent Deployment Stratejisi

Kurumsal ortamlarda yüzlerce sunucuya tek tek agent kurmaya kalkmak zaman kaybıdır. SCOM’un discovery ve push installation özelliklerini kullanmak, işi ciddi ölçüde hızlandırır. Ancak push installation her zaman sorunsuz çalışmaz; güvenlik duvarı kuralları, WMI erişim sorunları ve UAC gibi engeller çıkabilir.

# Belirli bir IP aralığındaki makineleri discovery için tarama
# SCOM Shell'den çalıştırın
$discoveryConfig = New-Object Microsoft.EnterpriseManagement.Configuration.ManagementPackDiscovery
$taskResult = Start-SCOMDiscovery `
    -IPRange "192.168.10.1-192.168.10.254" `
    -ManagementServer (Get-SCOMManagementServer -Name "scom-ms01.domain.local")

Büyük ortamlarda discovery yerine doğrudan script ile toplu kurulum yapmayı tercih ediyorum:

# Sunucu listesinden toplu agent kurulumu
$serverList = Get-Content "C:SCOMsunucu-listesi.txt"
$managementServer = Get-SCOMManagementServer -Name "scom-ms01.domain.local"
$agentApprovalSetting = [Microsoft.EnterpriseManagement.Administration.AgentApprovalSetting]::AutoApprove

foreach ($server in $serverList) {
    try {
        Install-SCOMAgent `
            -DNSHostName "$server.domain.local" `
            -ManagedByManagementServer $managementServer `
            -ActionAccount (Get-SCOMRunAsAccount -Name "Agent Action Account")
        Write-Host "$server - Agent kurulumu baslatildi" -ForegroundColor Green
    }
    catch {
        Write-Host "$server - Hata: $_" -ForegroundColor Red
        Add-Content -Path "C:SCOMhata-log.txt" -Value "$server: $_"
    }
}

Management Pack Yapılandırması

SQL Server MP’yi ele alalım. Microsoft SQL Server Management Pack’i içe aktardıktan sonra yapmanız gereken ilk şey, varsayılan eşik değerlerini kendi ortamınıza göre düzenlemektir.

Çoğu ortamda özellikle şu monitörleri özelleştirmeniz gerekir:

SQL Server için kritik override’lar:

  • Database Free Space: Default olarak %10’un altında uyarı verir. Büyük veritabanlarında bu değer yanıltıcı olabilir, MB bazında eşik belirlemek daha mantıklıdır.
  • SQL Server Blocking: Uzun süren blocking için eşiği ortamınıza göre ayarlayın.
  • Tempdb Free Space: Tempdb dolduğunda tüm SQL instance’ı durur, bu monitörü mutlaka etkin tutun.

Override’ları PowerShell ile yönetmek, GUI’den çok daha tutarlı sonuçlar verir:

# SQL DB Free Space monitörü için override oluşturma
$monitor = Get-SCOMMonitor -DisplayName "SQL DB Free Space (%)"
$managementPack = Get-SCOMManagementPack -Name "Overrides.SQL" 

# Eğer override MP yoksa oluşturun
if (-not $managementPack) {
    $managementPack = New-Object Microsoft.EnterpriseManagement.Configuration.ManagementPack(
        "Overrides.SQL",
        "SQL Override Management Pack",
        [Version]"1.0.0.0",
        $null
    )
}

# Warning eşiğini %15 olarak override etme
$class = Get-SCOMClass -DisplayName "SQL Server Database Engine"
New-SCOMMonitorOverride `
    -Monitor $monitor `
    -Parameter "Threshold" `
    -Value "15" `
    -ManagementPack $managementPack `
    -Enforced $false

Özel Performans Toplayıcıları Oluşturma

SCOM’un hazır MP’leri bazen izlemek istediğiniz her şeyi kapsamaz. Özellikle kurumsal uygulamalara özgü metrikleri toplamak için özel rule’lar oluşturmanız gerekir.

Bir finans kurumunda çalışırken, belirli bir Windows servisinin yanıt süresini Windows Performance Counter olarak raporlayan özel bir uygulamamız vardı. Bunu SCOM’da izlemek için şu yaklaşımı kullandık:

# Özel performans counter'ı SCOM'a eklemek için
# Önce counter'ın var olduğunu doğrulayın
$counterList = Get-Counter -ListSet "OzelUygulama*" | Select-Object -ExpandProperty CounterSetName

# SCOM Shell ile özel collection rule ekleme
$managementPack = Get-SCOMManagementPack -Name "Custom.Application.Monitoring"
$class = Get-SCOMClass -DisplayName "Windows Computer"

# Performance collection rule XML'i oluşturma
$ruleXml = @"
<Rule ID="Custom.Application.ResponseTime.Collection" 
      Enabled="true" 
      Target="Windows!Microsoft.Windows.Computer">
  <Category>PerformanceCollection</Category>
  <DataSources>
    <DataSource ID="DS" TypeID="Perf!System.Performance.DataProvider">
      <ComputerName>$$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$$</ComputerName>
      <CounterName>Response Time (ms)</CounterName>
      <ObjectName>OzelUygulama</ObjectName>
      <InstanceName>*</InstanceName>
      <Frequency>300</Frequency>
    </DataSource>
  </DataSources>
</Rule>
"@

Alarm Yönetimi ve Notification Yapılandırması

Daha önce de belirttiğim gibi alarm yorgunluğu en büyük sorunlardan biri. Bunu önlemek için katmanlı bir bildirim stratejisi oluşturun.

Notification Channel yapılandırması:

# E-posta notification channel oluşturma
$smtpChannel = Add-SCOMNotificationChannel `
    -Name "SMTP-Kritik-Alarmlar" `
    -EmailAddress "[email protected]" `
    -DisplayName "Kritik Alarm E-postası" `
    -From "[email protected]" `
    -SMTPServer "smtp.sirket.com.tr" `
    -SMTPAuthentication Anonymous `
    -Port 25 `
    -ReplyTo "[email protected]"

# Subscriber oluşturma
$subscriber = Add-SCOMNotificationSubscriber `
    -Name "NOC-Ekibi" `
    -Addresses @(
        New-SCOMNotificationSubscriberAddress `
            -Channel $smtpChannel `
            -Address "[email protected]"
    )

Subscription filter’ları:

Alarmları kritiklik seviyesine göre filtreleyip doğru kişilere göndermek şarttır:

# Sadece Critical seviye alarmları için subscription
$subscription = Add-SCOMNotificationSubscription `
    -Name "Kritik-Alarmlar-NOC" `
    -Subscriber $subscriber `
    -Channel $smtpChannel

# Severity filtresi ekleme (2 = Critical)
Set-SCOMNotificationSubscription `
    -Subscription $subscription `
    -CriteriaName "Severity" `
    -CriteriaValue "2"

Maintenance Mode Otomasyonu

Periyodik bakım pencerelerini her seferinde elle girmek hem zaman kaybı hem de hata riski oluşturur. Özellikle planlı Windows Update döngüleri için maintenance mode’u otomatikleştirmenizi öneririm.

# Belirli bir gruba maintenance mode uygulama
# Her Pazar 02:00-04:00 arası otomatik maintenance mode
$maintenanceGroup = Get-SCOMGroup -DisplayName "Windows-Sunucular-Prod"
$startTime = (Get-Date).Date.AddDays(7 - (Get-Date).DayOfWeek.value__).AddHours(2)
$endTime = $startTime.AddHours(2)

$maintenanceGroup | Start-SCOMMaintenanceMode `
    -EndTime $endTime `
    -Comment "Haftalık planlı bakım penceresi" `
    -Reason PlannedOperatingSystemReconfiguration

Write-Host "Maintenance mode baslatildi: $startTime - $endTime" -ForegroundColor Yellow

# Zamanlanmış görev ile her hafta otomatik çalıştırmak için
$action = New-ScheduledTaskAction `
    -Execute "PowerShell.exe" `
    -Argument "-NonInteractive -File C:SCOMScriptsMaintenanceMode.ps1"

$trigger = New-ScheduledTaskTrigger `
    -Weekly `
    -DaysOfWeek Sunday `
    -At "01:45AM"

Register-ScheduledTask `
    -TaskName "SCOM-Haftalık-MaintenanceMode" `
    -Action $action `
    -Trigger $trigger `
    -RunLevel Highest `
    -User "DOMAINsvc-scom"

Dashboard ve Raporlama

SCOM’un Operations Console’u günlük izleme için yeterli olsa da üst yönetime veya iş birimlerine rapor sunmak için daha anlaşılır panolar gerekebilir. SCOM’un Reporting Services entegrasyonu bu noktada devreye girer.

Sık ihtiyaç duyduğum raporlardan biri belirli bir dönemdeki alarm istatistikleridir:

# Son 7 günün alarm özetini PowerShell ile çekme
$startDate = (Get-Date).AddDays(-7)
$endDate = Get-Date

$alarmOzeti = Get-SCOMAlert `
    -ResolutionState @(0, 247, 248, 249, 255) `
    -Criteria "TimeRaised >= '$($startDate.ToString("yyyy-MM-dd"))'" | 
    Group-Object -Property Severity | 
    Select-Object @{
        Name = "Severity"; 
        Expression = {
            switch ($_.Name) {
                "2" { "Kritik" }
                "1" { "Uyarı" }
                "0" { "Bilgi" }
                default { "Bilinmiyor" }
            }
        }
    }, Count

$alarmOzeti | Format-Table -AutoSize

# CSV'ye aktarma
$alarmOzeti | Export-Csv `
    -Path "C:SCOMRaporlaralarm-ozeti-$(Get-Date -Format 'yyyyMMdd').csv" `
    -Encoding UTF8 `
    -NoTypeInformation

Yaygın Sorunlar ve Çözümleri

SCOM kurulumlarında karşılaştığım ve sizi haftalar süren uğraştan kurtarabilecek birkaç pratik noktayı paylaşayım.

Agent healthstate sorunu: Agentlar bazen “Not Monitored” veya “Grey” durumuna düşer. İlk yapılacak şey Management Server’dan agent’a bağlantıyı test etmektir:

# Agent health durumunu kontrol etme
Get-SCOMAgent | Where-Object { $_.HealthState -ne "Success" } | 
    Select-Object DisplayName, HealthState, LastModified |
    Sort-Object LastModified -Descending |
    Format-Table -AutoSize

# Sorunlu agent'ları yeniden başlatma
$problemliAgentlar = Get-SCOMAgent | Where-Object { $_.HealthState -eq "Error" }
foreach ($agent in $problemliAgentlar) {
    $managementServer = $agent.GetManagementServer()
    Invoke-Command -ComputerName $agent.DisplayName -ScriptBlock {
        Restart-Service "HealthService" -Force
        Write-Host "HealthService yeniden baslatildi" -ForegroundColor Green
    }
}

Yüksek CPU tüketen workflow’lar: SCOM bazen Management Server’da aşırı CPU kullanımına neden olur. Genellikle sebebi aşırı sık çalışan bir collection rule veya discovery’dir:

# En yoğun workflow'ları tespit etme
$workflows = Get-SCOMManagementPackRule | 
    Where-Object { $_.Enabled -eq $true } |
    Select-Object DisplayName, 
        @{Name="Frequency"; Expression={ 
            ($_.DataSourceCollection | Where-Object { $_.Parameters.ContainsKey("Frequency") }).Parameters["Frequency"] 
        }} |
    Sort-Object Frequency

$workflows | Where-Object { [int]$_.Frequency -lt 60 } | Format-Table -AutoSize

Güvenlik ve Erişim Yönetimi

SCOM’da role-based access control (RBAC) son derece önemli. Özellikle büyük organizasyonlarda farklı ekiplerin sadece kendi sunucularını görmesi gerekebilir.

SCOM’un built-in rolleri şunlardır:

  • Operations Manager Administrators: Tam yetki, sadece SCOM yöneticileri
  • Operations Manager Authors: MP oluşturabilir, yönetim görevi yapabilir
  • Operations Manager Operators: Alarm yönetimi yapabilir, maintenance mode açabilir
  • Operations Manager Read-Only Operators: Sadece görüntüleyebilir
  • Operations Manager Report Operators: Sadece rapor çalıştırabilir
  • Operations Manager Report Security Administrators: Rapor güvenliğini yönetir

Scope-based erişim için önce grup oluşturun, sonra role’e atayın. Örneğin veritabanı ekibi sadece SQL sunucularını görebilsin:

# SQL sunucuları için özel SCOM grubu oluşturma
$group = New-SCOMGroup `
    -Name "SQL.Sunucular.Prod" `
    -DisplayName "Production SQL Sunucular"

# SQL Server class'ına dahil tüm instance'ları gruba ekleme
$sqlClass = Get-SCOMClass -DisplayName "SQL Server Database Engine"
Add-SCOMClassInstance -Group $group -ClassInstance (Get-SCOMClassInstance -Class $sqlClass)

# DB ekibini bu gruba operator olarak atama
$role = Get-SCOMUserRole -DisplayName "DB-Ekibi-Operator"
if (-not $role) {
    Add-SCOMUserRole `
        -Name "DB-Ekibi-Operator" `
        -DisplayName "DB Ekibi Operatör" `
        -Role "operator" `
        -Group $group `
        -User "DOMAINdb-ekibi"
}

Sonuç

SCOM kurumsal Windows ortamları için güçlü bir araç ama gücü beraberinde karmaşıklık getiriyor. Bu yazıda aktardıklarımı özetleyecek olursam: Management Pack’leri default ayarlarıyla bırakmayın, alarm yorgunluğuna karşı erken önlem alın, Run As hesaplarını düzgün yapılandırın ve maintenance mode’u otomatikleştirin.

SCOM’un en değerli yanlarından biri, Microsoft’un kendi ürünleri için sunduğu hazır Management Pack ekosistemi. SQL Server, Active Directory ve Exchange için bunları doğru yapılandırdığınızda, bir sistem yöneticisinin elle takip etmesi imkansız olan yüzlerce kontrolü otomatik olarak yapabilirsiniz.

Bununla birlikte SCOM tek başına yeterli değil. Log yönetimi için Elastic Stack veya Splunk, uzun vadeli metrik depolama için InfluxDB gibi araçlarla entegre ettiğinizde gerçek anlamda kapsamlı bir izleme platformu elde edersiniz. SCOM’u, büyük bir izleme ekosisteminin Windows uzmanlığına sahip üyesi olarak konumlandırmak en doğru yaklaşım.

Son bir not: SCOM yatırımının karşılığını alabilmek için ekibinizin aracı gerçekten kullanması şart. En mükemmel yapılandırma bile, günlük olarak kontrol edilmeyen bir konsolda anlamsız kalır. Ekibiniz için düzenli SCOM review toplantıları ve alarm triage prosedürleri oluşturmak, teknik yapılandırma kadar kritik.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir