Windows Server Olay Günlüğü Nedir: Event Viewer Kullanımı

Tarafındankomut
0 Comments

Bir sistem yöneticisi olarak işlerin en karmaşık hale geldiği an, genellikle bir şeylerin sessizce bozulduğu andır. Sunucu yavaşlıyor, uygulama çöküyor ya da kullanıcılar “bir şeyler oldu” diye şikayet ediyor ama kimse tam olarak ne olduğunu bilmiyor. İşte tam bu noktada Windows Server’ın en güçlü silahlarından biri devreye giriyor: Olay Günlüğü (Event Log) ve onu görselleştiren Event Viewer.

Bu yazıda Event Viewer’ı sadece yüzeysel olarak tanıtmayacağım. Gerçek senaryolarla, PowerShell komutlarıyla ve pratik ipuçlarıyla bu aracı tam anlamıyla nasıl kullanacağınızı ele alacağız.

Windows Olay Günlüğü Nasıl Çalışır

Windows işletim sistemi, arka planda sürekli olarak olayları kaydeder. Bu olaylar; sistem başlangıcından uygulama hatalarına, güvenlik ihlali girişimlerinden donanım sorunlarına kadar geniş bir yelpazeyi kapsar. Bu kayıtlar .evtx uzantılı dosyalarda tutulur ve varsayılan olarak C:WindowsSystem32winevtLogs dizininde saklanır.

Olay Günlüğü mimarisi üç temel bileşenden oluşur:

  • Event Provider: Olayı üreten kaynak. Bu bir Windows servisi, uygulama veya kernel bileşeni olabilir.
  • Event Channel: Olayların ayrıştırıldığı mantıksal kanallar. Application, System, Security gibi.
  • Event Consumer: Olayları okuyan araçlar. Event Viewer, PowerShell, SIEM sistemleri vs.

Her olay kaydında şu bilgiler bulunur:

  • Event ID: Olayın benzersiz kimlik numarası
  • Level: Kritiklik seviyesi (Critical, Error, Warning, Information, Verbose)
  • Source: Olayı üreten uygulama veya servis
  • Date/Time: Olayın gerçekleştiği zaman damgası
  • Computer: Olayın gerçekleştiği makine adı
  • User: İlgili kullanıcı hesabı (varsa)

Event Viewer’ı Açmak ve Temel Gezinme

Event Viewer’ı açmanın birkaç yolu var:

# Run diyalogundan (Win + R)
eventvwr.msc

# Komut satırından
eventvwr

# PowerShell'den
Start-Process eventvwr.msc

Arayüz açıldığında sol panelde bir ağaç yapısı görürsünüz. Ana kategoriler şunlardır:

  • Custom Views: Kendi filtrelediğiniz görünümler
  • Windows Logs: Ana sistem günlükleri (Application, Security, Setup, System, Forwarded Events)
  • Applications and Services Logs: Spesifik uygulama ve servis günlükleri
  • Subscriptions: Uzak makinelerden topladığınız olaylar

Kritik Günlük Kanalları

Application Log: IIS, SQL Server, .NET uygulamaları gibi kullanıcı alanında çalışan uygulamaların hataları burada görünür. Bir web uygulaması çöktüğünde ilk bakacağınız yer.

System Log: Windows servisleri, sürücüler ve kernel bileşenlerinin ürettiği olaylar. Mavi ekran (BSOD) sonrası, disk hataları, ağ adaptörü sorunları hep burada.

Security Log: Başarılı ve başarısız oturum açma denemeleri, nesne erişimleri, politika değişiklikleri. Audit politikası aktifse bu log altın madeni.

Setup Log: Windows kurulumu ve güncelleme işlemleri. Bir Windows Update bozuk kurulduysa buraya bakın.

PowerShell ile Olay Günlüğü Sorgulamak

Event Viewer GUI olarak kullanışlı olsa da gerçek güç PowerShell ile gelir. Özellikle çok sayıda sunucuyu yönetiyorsanız veya otomatik izleme kuruyorsanız PowerShell vazgeçilmez.

Get-EventLog ile Temel Sorgular

# Son 20 sistem olayını listele
Get-EventLog -LogName System -Newest 20

# Sadece hata seviyesindeki olayları getir
Get-EventLog -LogName System -EntryType Error -Newest 50

# Belirli bir kaynaktan gelen olayları filtrele
Get-EventLog -LogName System -Source "Service Control Manager" -Newest 30

# Belirli tarih aralığında olayları sorgula
Get-EventLog -LogName Application -After "2024-01-01" -Before "2024-01-31" -EntryType Error

Get-WinEvent ile Gelişmiş Sorgular

Get-WinEvent, Get-EventLog‘dan çok daha güçlü ve modern bir cmdlet’tir. Özellikle Applications and Services Logs kanallarına erişmek için bu kullanılmalıdır:

# Son 1 saatte oluşan kritik ve hata olaylarını getir
$baslangic = (Get-Date).AddHours(-1)
Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    Level = 1,2  # 1=Critical, 2=Error
    StartTime = $baslangic
}

# Event ID'ye göre sorgulama (4625 = başarısız oturum açma)
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4625
    StartTime = (Get-Date).AddDays(-1)
} | Select-Object TimeCreated, Message | Format-List

# Birden fazla log kanalını aynı anda sorgula
Get-WinEvent -FilterHashtable @{
    LogName = 'System','Application'
    Level = 2
    StartTime = (Get-Date).AddHours(-6)
} | Sort-Object TimeCreated -Descending

XPath ile Kompleks Filtreler

Büyük ortamlarda XML tabanlı XPath sorguları çok işe yarar:

# XPath ile gelişmiş filtre - son 2 saatte EventID 7034 (servis beklenmedik şekilde sonlandı)
$xpath = "*[System[EventID=7034 and TimeCreated[timediff(@SystemTime) <= 7200000]]]"
Get-WinEvent -LogName System -FilterXPath $xpath

# Birden fazla Event ID için XPath
$xpath2 = "*[System[(EventID=7034 or EventID=7031 or EventID=7024) and TimeCreated[timediff(@SystemTime) <= 86400000]]]"
Get-WinEvent -LogName System -FilterXPath $xpath2 | Select-Object TimeCreated, Id, Message

Gerçek Dünya Senaryosu 1: Sunucu Gece Kendiliğinden Yeniden Başlıyor

Klasik senaryo: Sabah ofise geliyorsunuz, kullanıcılar “gece sunucu yeniden başladı” diyor. Event Viewer açıyorsunuz ve şunu yapıyorsunuz:

# Beklenmedik kapanma olaylarını bul (Event ID 6008)
Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    Id = 6008
    StartTime = (Get-Date).AddDays(-7)
} | Select-Object TimeCreated, Message | Format-List

# Kernel-Power olaylarını kontrol et (Event ID 41 = dirty shutdown)
Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    ProviderName = 'Microsoft-Windows-Kernel-Power'
    Id = 41
    StartTime = (Get-Date).AddDays(-7)
} | Format-List TimeCreated, Message

Event ID 6008 bulursanız bu beklenmedik kapanma demektir. Enerji kesilmesi, BSOD veya donanım arızası olabilir. Event ID 41 ise sistemin düzgün kapatılmadan kapandığını gösterir.

Ardından kapanma zamanının hemen öncesindeki olaylara bakarsınız:

# Sunucunun kapandığı zamanı bul ve önceki 10 dakikayı incele
$kapanmaZamani = (Get-WinEvent -FilterHashtable @{LogName='System'; Id=6008} -MaxEvents 1).TimeCreated
$aralikBaslangic = $kapanmaZamani.AddMinutes(-10)

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    StartTime = $aralikBaslangic
    EndTime = $kapanmaZamani
} | Sort-Object TimeCreated | Format-List TimeCreated, Id, Message

Gerçek Dünya Senaryosu 2: Brute Force Saldırısı Tespiti

Security log’u izlemek güvenlik açısından kritik. Özellikle RDP açık sunucularda başarısız oturum açma denemeleri alarm zili çalmalı:

# Son 24 saatte başarısız oturum açma denemelerini say (Event ID 4625)
$sonGun = (Get-Date).AddDays(-1)
$basarisizDeneme = Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4625
    StartTime = $sonGun
}

Write-Host "Son 24 saatte başarısız oturum açma sayısı: $($basarisizDeneme.Count)"

# IP adresine göre grupla ve en çok deneyenleri listele
$basarisizDeneme | ForEach-Object {
    $xml = [xml]$_.ToXml()
    $xml.Event.EventData.Data | Where-Object { $_.Name -eq 'IpAddress' } | Select-Object -ExpandProperty '#text'
} | Group-Object | Sort-Object Count -Descending | Select-Object -First 10 Name, Count

Eğer bir IP’den yüzlerce deneme görüyorsanız, bu bir brute force saldırısıdır. Windows Firewall veya bir WAF kuralıyla o IP’yi bloklayabilirsiniz.

Özel Görünümler (Custom Views) Oluşturmak

Event Viewer’da her seferinde filtreleme yapmak zaman kaybı. Custom Views özelliğiyle sık kullandığınız filtreleri kaydedebilirsiniz.

Sol panelde Custom Views üzerine sağ tıklayın, Create Custom View seçin:

  • Logged: Zaman aralığı
  • Event level: Hangi seviyeleri görmek istediğiniz
  • By log veya By source: Hangi kanaldan veya kaynaktan
  • Event IDs: Spesifik event ID’leri (virgülle ayırın, – ile hariç tutun)

Örnek kullanışlı Custom View ayarları:

  • Kritik Sistem Hataları: System + Application log, Level: Critical ve Error
  • Güvenlik Olayları: Security log, ID: 4624, 4625, 4648, 4672
  • Servis Arızaları: System log, Source: Service Control Manager, ID: 7034, 7031, 7023

Bu görünümleri XML olarak da dışa aktarıp başka sunuculara aktarabilirsiniz.

Olay Günlüğü Boyut Yönetimi

Bir süre sonra log dosyaları şişebilir. Her kanalın boyut limiti ve eski kayıtların ne yapılacağı ayarlanabilir:

# Tüm log kanallarını ve boyutlarını listele
Get-WinEvent -ListLog * | Select-Object LogName, FileSize, MaximumSizeInBytes, RecordCount | 
    Where-Object { $_.RecordCount -gt 0 } | 
    Sort-Object FileSize -Descending | 
    Select-Object -First 20 | 
    Format-Table -AutoSize

# Belirli bir log'un boyut limitini artır (Security log'u 500MB yap)
$log = Get-WinEvent -ListLog Security
$log.MaximumSizeInBytes = 524288000  # 500 MB
$log.SaveChanges()

# Log'u temizle (dikkatli kullanın!)
# wevtutil cl Application

Boyut limitine ulaşıldığında ne olacağını da belirleyebilirsiniz:

  • Overwrite events as needed: Eski kayıtların üzerine yaz (varsayılan)
  • Archive the log when full: Dolu olduğunda arşivle, yeni log başlat
  • Do not overwrite events: Dolunca yeni kayıt alma (tehlikeli, dikkat)

Kritik ortamlarda Security log için Archive modunu öneririm. Aksi halde saldırı kanıtları üzerine yazılabilir.

Uzak Sunuculardan Olay Toplama

Onlarca sunucuyu yönetiyorsanız, her birine tek tek bağlanıp log bakmak pratik değil. PowerShell’in gücünü kullanın:

# Uzak sunucudan olay çekme
Get-WinEvent -ComputerName "SUNUCU01" -FilterHashtable @{
    LogName = 'System'
    Level = 1,2
    StartTime = (Get-Date).AddHours(-4)
}

# Birden fazla sunucudan paralel log toplama
$sunucular = @("SUNUCU01", "SUNUCU02", "SUNUCU03", "SUNUCU04")
$hatalar = foreach ($sunucu in $sunucular) {
    try {
        Get-WinEvent -ComputerName $sunucu -FilterHashtable @{
            LogName = 'System','Application'
            Level = 2
            StartTime = (Get-Date).AddHours(-1)
        } -ErrorAction Stop | 
        Select-Object @{N='Sunucu';E={$sunucu}}, TimeCreated, Id, LevelDisplayName, Message
    }
    catch {
        Write-Warning "$sunucu - Bağlantı hatası: $_"
    }
}

# Sonuçları CSV'ye aktar
$hatalar | Export-Csv -Path "C:Raporlarsunucu-hatalari.csv" -Encoding UTF8 -NoTypeInformation
Write-Host "Toplam $($hatalar.Count) hata bulundu ve CSV'ye aktarıldı."

Windows Event Forwarding (WEF) Kurulumu

Merkezi log toplama için WEF harika bir çözüm. Collector sunucuda şunu çalıştırın:

# Collector servisini başlat
winrm quickconfig -quiet
wecutil qc -quiet

# Subscription oluşturma (XML dosyasından)
wecutil cs "C:subscription.xml"

# Mevcut subscription'ları listele
wecutil es

# Subscription durumunu kontrol et
wecutil gr "CriticalEvents"

Önemli Event ID’leri Ezberlemeniz Gerekmez Ama Bunları Bilin

Sık karşılaşacağınız ve ne anlama geldiğini bilmeniz gereken Event ID’ler:

System Log:

  • 7034: Servis beklenmedik şekilde sonlandı
  • 7031: Servis beklenmedik şekilde sonlandı, kurtarma eylemi alındı
  • 7023: Servis bir hatayla sonlandı
  • 6008: Beklenmedik sistem kapanması
  • 41: Kernel-Power, dirty shutdown
  • 1001: Windows Hata Raporlama (BSOD sonrası)

Security Log:

  • 4624: Başarılı oturum açma
  • 4625: Başarısız oturum açma
  • 4648: Açık kimlik bilgileri ile oturum açma girişimi
  • 4672: Özel ayrıcalıklar atandı (admin oturum açması)
  • 4720: Kullanıcı hesabı oluşturuldu
  • 4726: Kullanıcı hesabı silindi
  • 4740: Kullanıcı hesabı kilitlendi

Application Log:

  • 1000: Uygulama çökmesi
  • 1001: Windows Hata Raporlama
  • 1002: Uygulama yanıt vermedi

Log’ları Dışa Aktarmak ve Arşivlemek

# Event Viewer GUI'den dışa aktarma (komut satırı)
wevtutil epl System "C:Backupsystem-$(Get-Date -Format 'yyyyMMdd').evtx"
wevtutil epl Security "C:Backupsecurity-$(Get-Date -Format 'yyyyMMdd').evtx"
wevtutil epl Application "C:Backupapplication-$(Get-Date -Format 'yyyyMMdd').evtx"

# Log'u okunabilir XML formatında dışa aktar
wevtutil qe System /f:XML /c:100 > "C:Backupsystem-son100.xml"

# Haftalık arşiv scripti (Task Scheduler'a ekleyin)
$tarih = Get-Date -Format 'yyyy-MM-dd'
$hedefDizin = "\fileserverLogArsiv$env:COMPUTERNAME$tarih"
New-Item -ItemType Directory -Path $hedefDizin -Force

wevtutil epl System "$hedefDizinSystem.evtx"
wevtutil epl Security "$hedefDizinSecurity.evtx"
wevtutil epl Application "$hedefDizinApplication.evtx"

Write-Host "Arşivleme tamamlandı: $hedefDizin"

Olay Tabanlı Görev Oluşturmak

Event Viewer’ın az bilinen ama çok işe yarayan özelliği: Belirli bir olay tetiklendiğinde otomatik eylem başlatmak.

Örneğin, kritik bir servis çöktüğünde (Event ID 7034) size mail atmasını istiyorsanız:

Event Viewer’da ilgili olayı bulun, sağ tıklayın ve Attach Task to This Event seçin. Sihirbaz size şunları sunacak:

  • Bir program çalıştır (PowerShell script, batch dosyası)
  • Mail gönder (deprecated ama hala çalışır)
  • Mesaj göster

PowerShell ile aynısını Task Scheduler üzerinden de yapabilirsiniz, bu daha esnektir.

Audit Policy: Security Log’u Anlamlı Kılmak

Security log varsayılan olarak çok az şey kaydeder. Audit Policy aktif etmezseniz 4625 olayı bile göremeyebilirsiniz:

# Mevcut audit politikasını kontrol et
auditpol /get /category:*

# Oturum açma olaylarını denetlemeyi aktif et
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

# Hesap yönetimi olaylarını denetle
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable

# Nesne erişimini denetle
auditpol /set /subcategory:"File System" /success:enable /failure:enable

# Politika değişikliklerini denetle
auditpol /set /subcategory:"Audit Policy Change" /success:enable /failure:enable

Group Policy üzerinden merkezi olarak uygulamak için: Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration

Sonuç

Event Viewer ve Windows Olay Günlüğü, bir sistem yöneticisinin en değerli tanılama araçlarından biridir. Ancak bu araç, yüzeysel bilindiğinde anlamsız gürültüden ibaret görünür. Doğru filtreleri, doğru Event ID’leri ve PowerShell’in sorgu gücünü bir araya getirdiğinizde, sunucunuzda tam anlamıyla ne olduğunu görebilirsiniz.

Pratikte şu alışkanlıkları edinmenizi öneririm: Kritik sunucularda Security log boyutunu en az 1 GB yapın, WEF ile merkezi log toplama kurun ve sık karşılaştığınız sorunlar için Custom View’lar oluşturun. Bir sorun patlak verdiğinde saatlerce tahmin yürütmek yerine, birkaç dakika içinde kök nedeni bulabilmek hem size hem de kullanıcılarınıza büyük fayda sağlar.

Son olarak, log yönetimini reaktif değil proaktif bir süreç olarak ele alın. Sorun çıkmadan önce düzenli log taramalarını otomatize edin, eşik değerleri belirleyin ve kritik olaylar için uyarı mekanizmaları kurun. Sistemlerinizin size ne söylediğini dinleyin; genellikle büyük arızalar küçük uyarı işaretleri vererek gelir.

Bir yanıt yazın

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