Exchange Server İzleme: SCOM ve Üçüncü Parti Araçlarla Kapsamlı Monitoring

Yazar:komut.io ekibi Exchange Server Kurulum ve Yönetimi
0 Yorum

Exchange ortamını izlemek, birçok sysadmin’in “zaten çalışıyor” diyerek ertelediği ama ilk ciddi arızada pişman olduğu konuların başında gelir. Yıllar içinde farklı büyüklüklerde Exchange kurulumlarıyla çalıştım ve şunu net söyleyebilirim: proaktif izleme olmadan Exchange yönetmek, körün piyasada yürümesine benziyor. Bir şeylere çarpana kadar sorun olmadığını sanıyorsunuz.

Bu yazıda hem Microsoft’un kendi izleme altyapısı olan SCOM’u hem de üçüncü parti araçları ele alacağım. Hangisinin ne zaman mantıklı olduğunu, gerçek senaryolar üzerinden konuşacağız.

Exchange İzlemenin Temel Bileşenleri

Exchange Server’ı izlerken neye baktığınızı bilmezseniz, doğru araç da işe yaramaz. Önce izlenmesi gereken kritik alanları netleştirelim.

Mail Flow (Posta Akışı): En kritik unsur budur. Mesajların gönderilip alınıp alınmadığı, kuyruktaki mesaj sayısı ve gecikme süreleri anlık takip gerektirir.

DAG (Database Availability Group) Sağlığı: Birden fazla Exchange sunucunuz varsa DAG replikasyonunun durumu hayati önem taşır.

Transport Kuyrukları: Özellikle submission queue ve delivery queue’daki birikimler, mail flow sorunlarının ilk habercisidir.

Veritabanı Boyutu ve Büyüme Hızı: Disk dolmadan önce uyarı almak istiyorsunuz.

Client Access Hizmetleri: OWA, ActiveSync, MAPI bağlantılarının sağlığı.

CPU/Memory/Disk I/O: Exchange’in kaynak tüketimi, özellikle yoğun saatlerde.

SCOM ile Exchange İzleme

System Center Operations Manager, Microsoft’un kurumsal izleme platformudur. Exchange için özel hazırlanmış Management Pack’leri sayesinde oldukça derin bir izleme yapabilirsiniz. Ama gerçekçi olalım: SCOM kurulumu ve yapılandırması ciddi bir iş yükü getirir.

Exchange Management Pack Kurulumu

SCOM’a Exchange Management Pack’i eklemek için önce paketi indirip import etmeniz gerekiyor. Bunu PowerShell üzerinden yapabilirsiniz:

# SCOM Management Shell'de çalıştırın
Import-SCOMManagementPack -FullName "C:ManagementPacksMicrosoft.Exchange.2019.mp"
Import-SCOMManagementPack -FullName "C:ManagementPacksMicrosoft.Exchange.2019.Discovery.mp"

Management Pack import edildikten sonra Exchange sunucularınızın Discovery kapsamına girdiğinden emin olun. SCOM’un Exchange Agent’ını tanıması birkaç dakika ile birkaç saat arasında sürebilir, sabırlı olun.

SCOM’da Özel Monitor Tanımlama

Exchange Transport Service’in durumunu izlemek için özel bir monitor oluşturabilirsiniz. Aşağıdaki örnek, PowerShell üzerinden SCOM API’siyle çalışır:

# Transport Queue Monitor - PowerShell ile SCOM API
$mg = New-Object Microsoft.EnterpriseManagement.ManagementGroup("SCOMServer")
$healthService = $mg.GetMonitoringObjects("Microsoft.SystemCenter.HealthService")

# Queue boyutunu kontrol eden script monitor
$scriptBody = @'
$queue = Get-ExchangeDiagnosticInfo -Server $env:COMPUTERNAME -Process EdgeTransport -Component queues
$submissionQueue = $queue.Result.Diagnostics.Queue | Where-Object {$_.Name -eq "Submission"}
if ($submissionQueue.MessageCount -gt 500) {
    $bag = $ScriptApi.CreatePropertyBag()
    $bag.AddValue("QueueCount", $submissionQueue.MessageCount)
    $bag.AddValue("State", "Critical")
    $ScriptApi.Return($bag)
}
'@

Exchange Sunucusunda Diagnostic Log’ları Aktifleştirme

SCOM’un daha anlamlı veriler toplayabilmesi için Exchange tarafında diagnostic logging seviyelerini ayarlamanız gerekir:

# Exchange Management Shell'de
Set-EventLogLevel -Identity "MSExchangeTransportSmtpSend" -Level Expert
Set-EventLogLevel -Identity "MSExchangeTransportSmtpReceive" -Level Expert
Set-EventLogLevel -Identity "MSExchangeIS9000 PrivateReplication" -Level Medium

# Mevcut log seviyelerini görüntüle
Get-EventLogLevel | Where-Object {$_.EventLevel -ne "Lowest"} | Sort-Object Identity

SCOM’un Güçlü ve Zayıf Yanları

SCOM’u yıllarca kullananlar bilir: bu araç güçlüdür ama karmaşıktır. Gerçek bir kurumsal ortamda karşılaştığım somut bir senaryo paylaşayım.

Bir finansal kurumda, 8 Exchange sunucusundan oluşan bir DAG yapısını SCOM ile izliyorduk. Management Pack gayet iyi çalışıyordu, ancak şunu fark ettik: SCOM’un varsayılan eşikleri Türkiye’deki tipik iş saatleri için optimize edilmemişti. Sabah 08:30-09:30 arası, herkesin e-postasını açtığı yoğunluk pik noktası, SCOM’u gereksiz alarmlarla dolduruyor ve ekip “alarm yorgunluğu” yaşıyordu.

Çözüm: Override’lar kullanarak zaman tabanlı eşikler tanımladık.

# Override örneği - Mesai saatlerinde farklı eşik
# SCOM PowerShell ile
$override = New-SCOMManagementPackOverride -Rule -Name "ExchangeQueueThreshold.BusinessHours"
$override | Set-SCOMManagementPackOverride -Parameter Threshold -Value 1000 -Enforced $true

Üçüncü Parti İzleme Araçları

SCOM her ortam için doğru seçim olmayabilir. Özellikle sadece Exchange’i izlemek istiyorsanız, tam bir SCOM altyapısı kurmak overkill olabilir. İşte bu noktada üçüncü parti araçlar devreye giriyor.

Veeam ONE ile Exchange İzleme

Veeam ONE genellikle backup izleme aracı olarak bilinir ama Exchange altyapısını da izleyebilir. Özellikle Veeam Backup kullanan ortamlar için entegre bir izleme deneyimi sunar.

SolarWinds Server & Application Monitor (SAM)

SolarWinds SAM, Exchange için hazır şablonları olan ve kurulumu görece kolay bir araçtır. Mail flow testleri, kuyruk izleme ve OWA sağlık kontrolleri için kullanışlıdır.

Ancak lisans maliyeti ciddi olabilir. Küçük ve orta büyüklükteki Türk şirketleri için bütçe hesabı iyi yapılmalıdır.

Zabbix ile Exchange İzleme – Ücretsiz Ama Etkin

Bütçe kısıtlaması olan ortamlar için Zabbix mükemmel bir seçenek. Exchange’i Zabbix ile izlemek biraz daha fazla el emeği gerektirir ama sonuç tatmin edicidir.

Önce Zabbix Agent’ı Exchange sunucusuna kurun, ardından özel UserParameter’lar tanımlayın:

# zabbix_agentd.conf içine eklenecek satırlar
# Exchange Mail Queue monitoring
UserParameter=exchange.queue.submission,powershell -NoProfile -Command "(Get-ExchangeDiagnosticInfo -Server localhost -Process EdgeTransport -Component queues).Result.Diagnostics.Queue | Where-Object {$_.Name -eq 'Submission'} | Select-Object -ExpandProperty MessageCount"

UserParameter=exchange.queue.total,powershell -NoProfile -Command "(Get-ExchangeDiagnosticInfo -Server localhost -Process EdgeTransport -Component queues).Result.Diagnostics.Queue | Measure-Object MessageCount -Sum | Select-Object -ExpandProperty Sum"

UserParameter=exchange.dag.status,powershell -NoProfile -Command "Get-MailboxDatabaseCopyStatus | Where-Object {$_.Status -ne 'Mounted' -and $_.Status -ne 'Healthy'} | Measure-Object | Select-Object -ExpandProperty Count"

Zabbix template’ini oluştururken dikkat etmeniz gereken nokta: PowerShell çağrıları zaman zaman timeout’a girebilir. Zabbix’in Timeout parametresini varsayılan 3 saniyeden en az 15-30 saniyeye çıkarın.

Exchange Sağlık Kontrolü için Özel PowerShell Script’i

Bazen en iyi izleme aracı, kendi yazdığınız script’tir. Aşağıdaki script, Exchange ortamının genel sağlığını kontrol eder ve sonuçları log dosyasına yazar. Bu script’i Task Scheduler ile düzenli aralıklarla çalıştırabilir, çıktıyı Zabbix veya SCOM’a besleyebilirsiniz:

# Exchange-HealthCheck.ps1
param(
    [string]$LogPath = "C:LogsExchangeHealth",
    [int]$QueueThreshold = 100,
    [int]$DiskFreeThreshold = 15  # Yüzde olarak
)

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn -ErrorAction SilentlyContinue

$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
$results = @()

# Mail Queue Kontrolü
$queues = Get-Queue -Filter {MessageCount -gt 0} | Select-Object Identity, MessageCount, Status, NextHopDomain
foreach ($queue in $queues) {
    $status = if ($queue.MessageCount -gt $QueueThreshold) { "CRITICAL" } else { "OK" }
    $results += [PSCustomObject]@{
        Component = "Queue"
        Name = $queue.Identity
        Value = $queue.MessageCount
        Status = $status
        Timestamp = $timestamp
    }
}

# DAG Replikasyon Durumu
$dagStatus = Get-MailboxDatabaseCopyStatus -ErrorAction SilentlyContinue
foreach ($db in $dagStatus) {
    $status = if ($db.Status -in @("Mounted","Healthy")) { "OK" } else { "WARNING" }
    $results += [PSCustomObject]@{
        Component = "DAG"
        Name = $db.Name
        Value = $db.Status
        Status = $status
        Timestamp = $timestamp
    }
}

# Disk Alanı Kontrolü
$exchangeDisks = Get-MailboxDatabase -Status | Select-Object Name, EdbFilePath
foreach ($db in $exchangeDisks) {
    $drive = Split-Path $db.EdbFilePath.PathName -Qualifier
    $diskInfo = Get-PSDrive ($drive -replace ":","") -ErrorAction SilentlyContinue
    if ($diskInfo) {
        $freePercent = [math]::Round(($diskInfo.Free / ($diskInfo.Used + $diskInfo.Free)) * 100, 2)
        $status = if ($freePercent -lt $DiskFreeThreshold) { "CRITICAL" } else { "OK" }
        $results += [PSCustomObject]@{
            Component = "Disk"
            Name = $db.Name
            Value = "$freePercent%"
            Status = $status
            Timestamp = $timestamp
        }
    }
}

# Sonuçları log'a yaz
if (-not (Test-Path $LogPath)) { New-Item -ItemType Directory -Path $LogPath }
$results | Export-Csv -Path "$LogPathhealth_$(Get-Date -Format 'yyyyMMdd').csv" -Append -NoTypeInformation

# Kritik durumları konsola bas
$criticals = $results | Where-Object {$_.Status -eq "CRITICAL"}
if ($criticals) {
    Write-Warning "KRITIK DURUMLAR:"
    $criticals | Format-Table -AutoSize
    exit 1
}
exit 0

Mail Flow Testleri ve Otomasyonu

İzlemenin sadece altyapı sağlığına bakması yeterli değil. Gerçekten mesaj gidip geliyor mu, bunu test etmek de kritik. Exchange Server’ın kendi Test-Mailflow cmdlet’i bu iş için biçilmiş kaftan:

# Test-Mailflow ile end-to-end mail testi
$result = Test-Mailflow -TargetMailboxServer EXCH-MBX02 -ErrorAction SilentlyContinue

if ($result.TestMailflowResult -ne "Success") {
    Write-Warning "Mail flow testi BASARISIZ: $($result.MessageLatencyTime)"
    # Burada alert mekanizmanızı tetikleyin
} else {
    Write-Host "Mail flow OK - Gecikme: $($result.MessageLatencyTime.TotalMilliseconds) ms"
}

# Tüm DAG üyelerine karşı toplu test
$servers = Get-MailboxServer
foreach ($server in $servers) {
    $test = Test-Mailflow -TargetMailboxServer $server.Name -ErrorAction SilentlyContinue
    Write-Host "[$($server.Name)] Sonuc: $($test.TestMailflowResult) | Gecikme: $($test.MessageLatencyTime)"
}

Bu testi her 5-10 dakikada bir çalıştıracak şekilde Task Scheduler’a ekleyebilir ve sonuçları izleme sisteminize besleyebilirsiniz.

Gerçek Dünya Senaryosu: Sessiz Ölüm Vakası

Bir üretim firmasında yaşanan olayı paylaşmak istiyorum. Exchange ortamı teknik olarak “çalışıyordu”. SCOM alarmı yoktu, servislerin hepsi ayaktaydı. Ancak dışarıdan gelen bazı mailler saatler sonra ulaşıyordu.

Sorun neydi? Connector üzerindeki MaxMessageSize limiti, belirli bir tedarikçiden gelen büyük PDF ekli mailleri yavaşlatıyordu. Mesajlar kuyrukta birikmiyor, teslim ediliyordu ama çok geç.

Bu tür sessiz sorunları yakalamak için latency bazlı izleme şart:

# Message Tracking Log analizi ile gecikme tespiti
$startTime = (Get-Date).AddHours(-1)
$slowMessages = Get-MessageTrackingLog -Start $startTime -EventId "DELIVER" |
    Where-Object {
        ($_.Timestamp - $_.MessageInfo.OriginalArrivalTime).TotalMinutes -gt 10
    } |
    Select-Object Timestamp, Sender, Recipients, MessageSubject,
        @{Name="DeliveryDelayMinutes"; Expression={
            [math]::Round(($_.Timestamp - $_.MessageInfo.OriginalArrivalTime).TotalMinutes, 2)
        }}

$slowMessages | Sort-Object DeliveryDelayMinutes -Descending | Select-Object -First 20

Bu sorguyu düzenli çalıştırıp sonuçları izleme sisteminize entegre etmek, sessiz kalan sorunları yüzeye çıkarır.

Prometheus ve Grafana ile Modern İzleme

Daha modern bir yaklaşım isteyenler için: windows_exporter ve Exchange’e özel custom collector kullanarak Prometheus metriklerini toplayıp Grafana dashboard’larında görselleştirebilirsiniz.

windows_exporter’ı Exchange sunucusuna kurduktan sonra IIS ve Process collector’larını aktif edin:

# windows_exporter'ı Exchange metrikleri için başlatma
# Komut satırından veya servis parametresi olarak:
windows_exporter.exe --collectors.enabled="cpu,cs,logical_disk,net,os,process,iis,exchange"

# Exchange collector'ın topladığı metrikler Prometheus'tan sorgulanabilir:
# windows_exchange_transport_queues_active_messages
# windows_exchange_transport_queues_submission_queue_items_total
# windows_exchange_is_store_reads_per_sec
# windows_exchange_is_store_writes_per_sec

Grafana tarafında bu metrikleri kullanan bir dashboard oluşturduğunuzda, Exchange ortamınızın anlık fotoğrafını net bir şekilde görebilirsiniz. Özellikle DAG replikasyon gecikmeleri ve transport kuyruk trendleri için bu görselleştirme çok değerlidir.

Alert Yorgunluğunu Önlemek

Her izleme sisteminin kronik sorunlarından biri: çok fazla alert üretmek. Ekip zamanla bu alertleri görmezden gelmeye başlıyor ve gerçek kritik bir durum kayıt altına alınmıyor.

Exchange izlemede alert yorgunluğunu önlemek için birkaç pratik yaklaşım:

Baseline oluşturun: İlk iki hafta izleme sistemini sadece veri toplama modunda çalıştırın. Neyin normal olduğunu anlayın, sonra eşikler belirleyin.

Alert kategorileri tanımlayın: Her uyarı aynı öneme sahip değil. P1 (hemen müdahale), P2 (mesai saatinde müdahale) ve P3 (haftalık review) şeklinde sınıflandırın.

Suppress window’ları kullanın: Sabah login piki, backup saatleri gibi bilinen yoğunluk dönemleri için alert bastırma kuralları tanımlayın.

Correlation kuralları ekleyin: Bir DAG sunucusu kapalıysa, o sunucuyla ilgili 50 ayrı alert üretmek yerine tek bir “DAG üyesi erişilemez” alarmı oluşturun.

Araç Seçimi: Karar Kriterleriniz

Hangi izleme çözümünü seçeceğiniz ortamınıza ve kaynaklarınıza göre değişir.

SCOM tercih edin eğer:

  • Zaten Microsoft System Center altyapınız varsa
  • Büyük ve karmaşık bir Exchange ortamınız varsa (100+ mailbox server)
  • Exchange dışındaki Microsoft servisleriyle entegre izleme istiyorsanız
  • Dedicated Operations ekibiniz varsa

Zabbix veya Prometheus/Grafana tercih edin eğer:

  • Bütçe kısıtlamanız varsa
  • Küçük-orta ölçekli Exchange ortamınız varsa
  • Linux tabanlı izleme altyapınızla entegrasyon istiyorsanız
  • Özelleştirme özgürlüğüne değer veriyorsanız

SolarWinds, PRTG gibi ticari araçları tercih edin eğer:

  • Hızlı kurulum ve hazır şablonlar önceliğinizse
  • SCOM’u kuracak teknik kapasiten ama lisansın yoksa
  • Vendor desteği kritik bir gereksiniminizse

Sonuç

Exchange izleme, “kurup unuttum” mantığıyla çalışmaz. Ortamınız değiştikçe, kullanıcı sayısı arttıkça, yeni connector’lar ve kurallar eklendikçe izleme sisteminizi de güncellemeniz gerekir.

SCOM güçlü ama ağır bir çözüm. Zabbix esnek ama el emeği ister. Prometheus/Grafana ikilisi modern ama Exchange özelinde biraz daha kurulum gerektirir. Hangisini seçerseniz seçin, şu üç şeyi mutlaka izleyin: mail flow sağlığı, transport kuyrukları ve DAG replikasyon durumu. Geri kalan her şey bu temelin üzerine inşa edilebilir.

Proaktif izleme yapmak, saat 02:00’de telefon çalmasını beklemekten çok daha az streslidir. Bunu deneyimle söylüyorum.

Bir yanıt yazın

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