Windows Server, binlerce işletme için BT altyapısının temel taşı olmaya devam etmektedir. Eski bir uygulama, modern bir .NET ortamı veya kritik bir veritabanı çalıştırıyor olsanız da Windows sunucularınızın sağlığını güvence altına almak zorunludur. Bu; huzurlu bir gece ile sabahın 2’sinde acil sorun giderme arasındaki farktır.
2026’da Windows izleme ortamı gelişti. Basit uptime kontrollerinin çok ötesine geçtik. Modern ekipler; sistem performansı, güvenlik sinyalleri ve uygulama günlükleri hakkında daha derin bir görünürlük istiyor. Ancak Windows izleme çoğu zaman iki aşırı uç arasında bir seçim gibi hissettiriyor. Bir tarafta güçlü ama parçalı Microsoft yerleşik araçları; diğer tarafta ise aşırı karmaşık ve pahalı kurumsal gözlemlenebilirlik platformları.
Bu rehber bu boşluğu doldurmayı amaçlamaktadır. Windows izlemenin temel ilkelerini, takip etmeniz gereken metrikleri ve kurumsal yük olmadan bunu etkili biçimde yapmanıza yardımcı olan araçları inceleyeceğiz.
Windows izleme nedir?
Windows izleme; Windows işletim sisteminizden ve üzerinde çalışan uygulamalardan sürekli olarak veri toplama ve analiz etme sürecidir. Sunucunun fiziksel ve sanal kaynaklarının beklenen parametreler dahilinde çalıştığından emin olmak için gözlemlenmesini kapsar.
Yaygın bir hata, izlemeyi yalnızca bir gösterge paneli olarak düşünmektir. Gerçekte etkili Windows izleme üç katmandan oluşur.
Altyapı metrikleri
Bunlar, donanımınızın veya sanal makinenizin “hayati belirtilerini” temsil eden sayısal değerlerdir. CPU kullanımı, bellek baskısı ve disk gecikmesi bunların başında gelir. Genellikle Performans Sayaçları (PerfMon) aracılığıyla toplanırlar.
Olay günlükleri
Windows, sistemde gerçekleşen neredeyse her şeyi Olay Günlükleri içinde kaydeder. Buraya; servis başlatma/durdurma olayları, uygulama çökmeleri, güvenlik girişleri ve sistem hataları dahildir. Metrikler bir sorunun ne zaman gerçekleştiğini söylüyorsa, günlükler neden gerçekleştiğini söyler.
Uygulama sağlığı
Bu katman, kullanıcılarınızın gerçekten önem verdiği yazılıma odaklanır. IIS isteklere yanıt veriyor mu? SQL Server arabellek önbelleği isabet oranı sağlıklı mı? Uygulama katmanını izlemek; sunucu “açık” olsa bile servisin gerçekten çalışıp çalışmadığını garanti eder.
Windows izlemenin Linux izlemeden farkı
Linux dünyasından geliyorsanız Windows izleme size yabancı gelebilir. Linux’ta “her şey bir dosyadır” ve genellikle /proc içindeki metin dosyalarını okuyarak metrik toplarsınız.
Windows daha yapılandırılmış bir yaklaşım kullanır. Performans verilerinin neredeyse tamamı Performans Sayacı sistemi aracılığıyla sunulur. Bu verilere erişim geleneksel olarak özel API’ler veya WMI (Windows Yönetim Araçları) gerektiriyordu. WMI güçlü olsa da kaynak kullanımıyla ün kazanmıştır. 2026’da modern izleme araçları, Performans Sayacı API’si veya özel dışa aktarıcılar gibi daha verimli yöntemlere odaklanmaktadır.
Performans sayaçları vs. WMI
| Özellik | WMI | Performans Sayaçları |
|---|---|---|
| Nedir | İşletim sistemi verilerini ve operasyonlarını yönetmek için altyapı. | Yüksek frekanslı veri toplama mekanizması. |
| Görünürlük | Neredeyse her şey (seri numaraları, CPU sıcaklığı). | Bellekte gerçek zamanlı güncellenen sayısal değerler. |
| Yük | Yüksek CPU yüküyle bilinir; performans sorunlarına neden olabilir. | Sorgulama için çok daha verimli ve “ucuz”. |
Modern izleme ajanlarının çoğu, CPU ve disk kullanımı gibi metrikleri takip etmek için Performans Sayacı API’sini tercih eder; WMI’yi yalnızca işletim sistemi sürümü veya toplam fiziksel RAM gibi nadiren değişen statik bilgiler için saklar.
# Mevcut işlemci performans sayaçlarını listele
Get-Counter -ListSet Processor | Select-Object -ExpandProperty Counter
# Her 1 saniyede bir gerçek zamanlı CPU kullanımını sorgula
Get-Counter -Counter "\Processor(_Total)\% Processor Time" -SampleInterval 1 -MaxSamples 5
Windows’ta ne izlenmeli?
CPU performansı ve darboğazlar
CPU kullanımı en görünür metrik olmakla birlikte, genellikle gecikmeli bir göstergedir. Yalnızca bir yüzdeye bakmak yeterli değildir.
| Metrik | Açıklama | Kritik Eşik |
|---|---|---|
| % İşlemci süresi | Temel kullanım. | Sürekli > %80 |
| İşlemci kuyruğu uzunluğu | CPU bekleyen iş parçacıkları. | Çekirdek sayısının 2 katından fazla |
| Bağlam geçişi/sn | İş parçacıklarını yöneten CPU yükü. | Yüksek/olağandışı anlık artışlar |
Bellek ve kaynak baskısı
Windows, önbelleğe alma için RAM’i agresif biçimde kullanır. Yüksek bellek kullanımı her zaman kötü bir işaret değildir, ancak bellek baskısı görülmesi önemli bir sorundur.
| Metrik | Açıklama | Risk |
|---|---|---|
| Kullanılabilir MBayt | İşletim sistemi/uygulamalar için kalan fiziksel bellek. | Toplam RAM’in < %5-10’u |
| Sayfa/sn | Zorunlu sayfa hataları (diske takas). | Yüksek oranlar performansı ciddi düşürür |
| Taahhüt edilen baytlar | Toplam sanal bellek kullanımı. | RAM + Sayfa dosyasına yaklaşıyor |
Disk G/Ç ve gecikme
Disk performansı “sessiz” yavaşlığın en yaygın nedenidir. Bir sunucu %0 CPU yükü gösterirken disk alt sistemi aşırı yüklü olduğu için tamamen yanıt vermez hale gelebilir.
| Metrik | Açıklama | Hedef |
|---|---|---|
| Ort. Disk sn/Okuma ve Yazma | Saniye cinsinden gecikmeyi ölçer. | < 10ms (Mükemmel), > 50ms (Darboğaz) |
| % Disk süresi | Diskin meşgul olduğu sürenin yüzdesi. | Sürekli yüksek kullanım risklidir |
| Disk kuyruğu uzunluğu | Diski bekleyen G/Ç istekleri. | Yüksek gecikmeyle ilişkilendir |
Ağ verimi ve sağlığı
| Metrik | Açıklama | Hedef |
|---|---|---|
| Toplam bayt/sn | Temel bant genişliği kullanımı. | Ani artışları/transferleri tespit et |
| Çıkış kuyruğu uzunluğu | Gönderilmeyi bekleyen paketler. | 0 olmalı |
| Alınan paket hataları | Bozuk veya başarısız paketler. | 0 olmalı |
Windows servis ve süreçlerini izleme
# Belirli bir servisin durumunu kontrol et (örn. IIS)
Get-Service -Name W3SVC
# Otomatik başlatılacak şekilde yapılandırılmış ancak şu anda durmuş tüm servisleri listele
Get-Service | Where-Object { $_.StartType -eq 'Automatic' -and $_.Status -eq 'Stopped' }
- Servis sağlığı: “Otomatik” olarak ayarlanmış ancak “Durdurulmuş” durumda olan bir servis, büyük olasılıkla çökme veya başarısız bağımlılıktan kaynaklanan açık bir sorun sinyalidir.
- Süreç çalışma seti: Belirli bir süreç tarafından kullanılan fiziksel bellek miktarını ölçer. Bir uygulamanın çalışma seti hiç düşmeden büyümeye devam ediyorsa bellek sızıntısı vardır.
- Süreç başına tanıtıcı sayısı: “Tanıtıcı”, bir sistem kaynağına (dosya veya kayıt defteri anahtarı gibi) yapılan bir başvurudur. Sürekli artıyorsa süreç kaynakları serbest bırakmakta başarısız olmaktadır ve bu sonunda sistem genelinde kararsızlığa yol açar.
- Kullanıcı girişi gecikmesi: Uzak Masaüstü (RDS) ortamlarında, bir kullanıcının girişi ile uygulamanın yanıtı arasındaki gecikmeyi izlemek, donanım metriklerinin kaçırabileceği gerçek kullanıcı deneyimini anlamak için kritik öneme sahiptir.
Windows olay günlükleri
Metrikler “ne”yi söyler; Olay Günlükleri ise “kim”i ve “nasıl”ı. Bu dört ana günlüğe odaklanmalısınız:
- Sistem günlüğü: Donanım sorunları, sürücü hataları ve işletim sistemi düzeyindeki hatalar için kritiktir.
- Uygulama günlüğü: Yazılımınızın (ve üçüncü taraf uygulamaların) hata ve uyarılarını kaydettiği yer.
- Güvenlik günlüğü: Denetim için vazgeçilmezdir. Başarısız oturum açma girişimlerini, hesap kilitlemelerini ve yönetici gruplarındaki değişiklikleri izlemelisiniz.
- Kurulum günlüğü: Güncellemeler ve yeni yazılım kurulumlarında faydalıdır.
# Sistem günlüğünden son 10 hata olayını al
Get-WinEvent -LogName System -MaxEvents 10 | Where-Object { $_.LevelDisplayName -eq "Error" }
# Son 24 saatteki tüm 'Kritik' olayları listele
Get-WinEvent -FilterHashtable @{LogName='System'; Level=1; StartTime=(Get-Date).AddDays(-1)}
2026’da bu günlükleri Olay Görüntüleyicisi’nde manuel olarak kaydırmamalısınız. Belirli “Hata” veya “Kritik” düzeyindeki olayları merkezi hale getirip bunlar için uyarı almanız gerekmektedir.
Yaygın yaklaşımlar ve araçlar
Microsoft yerel araçları (Sysinternals ve PerfMon)
- Kimler için: Anlık sorun giderme ve belirli performans sorunlarının derinlemesine analizi.
- Artıları: Ücretsiz, yerleşik (veya kolayca indirilebilir) ve son derece ayrıntılı.
- Eksileri: Birden fazla sunucu genelinde merkezi uyarı veya geçmiş depolama yoktur. Sunucu sunucu, manuel bir yaklaşımdır.
Açık kaynak yığınları (Prometheus ve Grafana)
2026’da en popüler açık kaynak yaklaşımı; metrikleri toplamak için windows_exporter kullanmak ve bunları görselleştirme için Grafana ile birlikte bir Prometheus sunucusuna göndermektir.
- Kimler için: Windows filolarını izlemek için kendi Linux tabanlı izleme altyapısını yönetmeye hazır ekipler.
- Artıları: Yüksek düzeyde özelleştirilebilir, geniş ekosistem ve yazılım için lisans maliyeti yok.
- Eksileri: Önemli operasyonel yük. Dışa aktarıcıları, Prometheus sunucusunu ve Grafana gösterge panellerini kendiniz yönetmeniz gerekir.
Simple Observability

Simple Observability, geleneksel yığınların karmaşıklığı olmadan Windows sunucularındaki metrikleri, günlükleri ve uyarıları izlemek için hafif ve birleşik bir yaklaşım sunar. Tek komutla kurulum ile birden fazla sunucuda üretim düzeyinde görünürlük isteyen ekipler için “kur ve unut” çözümü olarak tasarlanmıştır.
- Kimler için: Tek komutlu kurulumla birden fazla sunucuda üretim düzeyinde görünürlük isteyen sistem yöneticileri ve geliştiriciler.
- Artıları: Metrikleri ve olay günlüklerini tek bir arayüzde birleştirir, kritik Windows uyarılarını otomatik olarak ayarlar ve çok düşük kaynak ayak izi sunar.
- Eksileri: Binlerce sunucuya sahip işletmeler ve son derece özel gereksinimler için tasarlanmamıştır.
Kurumsal platformlar (Zabbix, SolarWinds, Dynatrace)
- Kimler için: Büyük ve heterojen ortamlara sahip büyük işletmeler.
- Artıları: Kapsamlı özellikler ve profesyonel destek.
- Eksileri: Pahalı lisanslama, dik öğrenme eğrisi ve genellikle izleme aracını yönetmek için özel bir ekip gerektirir.
Windows izleme araçları karşılaştırması
| Araç | Tür | Karmaşıklık | En İyi Kullanım Alanı |
|---|---|---|---|
| PerfMon | Yerel Araç | Düşük | Hızlı yerel hata ayıklama |
| Prometheus | Açık Kaynak | Yüksek | Özel/kendin yap filolar |
| Simple Observability | SaaS/Birleşik | Düşük | Küçük-orta ekipler |
| Zabbix | Kurumsal | Yüksek | Büyük ölçekli ortamlar |
| Datadog | SaaS/APM | Orta | Tam yığın gözlemlenebilirlik |
Windows izleme için en iyi uygulamalar
Ekiplerin yaptığı en büyük hatalardan biri çok fazla uyarı ayarlamaktır. CPU birkaç saniyeliğine %90’a her çıktığında e-posta alırsanız, kısa sürede gelen kutunuzu görmezden gelmeye başlarsınız. Buna “uyarı yorgunluğu” denir.
Bunun yerine süregelen sorunlara odaklanın. Uyarılarınızı yalnızca bir metrik belirli bir süre (örn. 5-10 dakika) boyunca eşiğin üzerinde kaldığında tetiklenecek şekilde ayarlayın. Windows için özellikle Sistem ve Uygulama günlüklerindeki “Kritik” ve “Hata” olaylarını uyarıya bağladığınızdan emin olun; ancak “Bilgi” gürültüsünü filtreleyin.
Performans temeli oluşturun
Sunucunuzun kötü performans gösterip göstermediğini, “normal”in nasıl olduğunu bilmeden anlayamazsınız. İzlemeyi kurduktan sonra bir hafta boyunca metrikleri gözlemleyin. İş saatlerinde tipik CPU yükü nedir? RAM’in ne kadarı genellikle boş kalır? Genel varsayılanlara güvenmek yerine gerçekçi uyarı eşikleri belirlemek için bu verileri kullanın.
Hafif ajanlar kullanın
Windows sunucuları genellikle kaynak kısıtlıdır. Ağır Java tabanlı ajanlar kullanan veya WMI’ya yoğun biçimde bağımlı olan izleme araçlarından kaçının. Ana sistemin CPU ve belleği üzerinde minimum etkiye sahip Go veya Rust gibi performanslı dillerde yazılmış ajanlar arayın. Hafiflik bir metriktir, yalnızca bir sıfat değil — ve her bileşende verimliliği ön planda tutuyoruz.
Metrikleri ve günlükleri birleştirin
Metrikleri hiçbir zaman izole olarak izlemeyin. CPU kullanımındaki bir artış, bunu Olay Günlüğü’ndeki bir hatayla ilişkilendiremiyorsanız çok az anlam taşır. Grafiklerinizi ve günlüklerinizi aynı zaman çizelgesinde görebildiğiniz birleşik bir yaklaşım, “Ortalama Çözüm Sürenizi” (MTTR) önemli ölçüde azaltacaktır.
Dışarıdan içeriye izleyin
İç metrikler sunucunun sağlıklı olup olmadığını söyler, ancak kullanıcılarınızın uygulamanıza gerçekten erişip erişemediğini söylemez. Dahili Windows izlemenizi her zaman harici uptime kontrolleriyle birleştirin. Bu sayede sunucu “yeşil” görünse bile bir güvenlik duvarı değişikliği veya DNS sorunu bağlantıyı keserse uyarı alırsınız.
Sonuç
2026’da Windows izleme, “karmaşık” ile “eksik” arasında bir seçim olmak zorunda değildir. Temel sinyallere — CPU kuyruklarına, bellek baskısına, disk gecikmesine ve kritik olay günlüklerine — odaklanarak ihtiyaçlarınızla büyüyen sağlam bir izleme stratejisi oluşturabilirsiniz.
Prometheus ile özel bir yığın kurmayı, yerel hata ayıklama için Microsoft’un yerleşik araçlarını kullanmayı veya Simple Observability gibi birleşik bir platform seçmeyi tercih etseniz de kilit nokta; reaktif sorun gidermeden proaktif yönetime geçmektir.
Kullanıma hazır bir Windows izleme çözümü arayan ekipler için Simple Observability, tek komutlu kurulum ve birleşik metrikler + günlükler sunar. İzlemenizi yönetmek için daha az, altyapınızı yönetmek için daha fazla zaman harcamanızı sağlar.