Windows Server’da Production Network Troubleshooting: Netsh Trace’ten Pktmon’a 2012–2025 Operasyonel Rehber

İyi bir BT operasyonunun kalbinde basit bir ilke yatar: En yalın, en doğrulanmış ve en az ayrıcalık gerektiren çözüm, genellikle en güçlü olanıdır. Kritik bir ağ sorunu karşısında yeni bir yazılımın kurulum onayı için haftalarca beklemek ya da işletim sistemimizin sunduğu yerleşik teşhis yeteneklerini göz ardı etmek, bu stratejik ilkeyle çelişir.

Windows Server, ağ sorunlarını kökünden anlamamızı sağlayan ve kurulum gerektirmeyen güçlü araçları yıllar içinde sessizce geliştirdi. Bugün size sadece bir komut satırı aracını değil; Windows ekosisteminde ağ analizinin evrimini, Server 2012’den Server 2025’e kadar bu işi nasıl ‘kitabına göre’ yapacağınızı anlatacağım. Bilenler bilir; burada Amerika’yı yeniden keşfetmiyoruz; elimizdeki güçlü envanteri en verimli şekilde nasıl kullanacağımızı konuşuyoruz.

(Not: Bu makale, OSI modeli bağlamında Katman 3 ve 4 (Ağ ve Taşıma) teşhisine odaklanır; uygulama seviyesi (L7) performans analizleri veya kod hata ayıklama süreçleri kapsam dışıdır.)“

Geçmişle Yüzleşmek: Server 2012 & 2016’da Netsh Trace İle Hayatta Kalmak

Hepimizin envanterinde hala Server 2012 R2 veya 2016 gibi emektar sistemler var değil mi? Pktmon’un olmadığı bu dünyada, elimizdeki tek yerleşik can simidi netsh trace.

netsh trace start capture=yes tracefile=C:\Logs\LegacyTrace.etl maxsize=1024 persistent=yes

Bakın şunu net söyleyeyim: Bu komut, üçüncü parti yazılımla uğraşmadan temel yakalama yapmanızı sağlıyor. Ama işin acı gerçeği şu: oluşan .etl dosyasını doğrudan analiz edemezsiniz. Wireshark’ta açmak için mutlaka etl2pcap gibi harici bir dönüştürücüye ihtiyacınız var. Bu ek adım, sorun çözme sürenize ortalama 15-30 dakika ekliyor. O yüzden bu eski sistemlerdeki olay maliyetini hesaplarken, bu dönüştürme sürecini ne kadar otomatize ettiğinize mutlaka bakın.

Modern Standardı Kurmak: Server 2019/2022’de Pktmon Devrimi

Windows Server 2019 ile hayatımıza giren Packet Monitor (Pktmon), benim için sadece bir paket yakalayıcı değil. O, Windows ağ yığınının içine girip bize “paket neden düştü?” sorusunun cevabını verebilen bir operasyonel istihbarat gücü.

Peki, Bu Gücü Operasyonel Bir Disipline Nasıl Dönüştürürüz?

Arkadaşlar, Pktmon’u kullanırken sadece komut yazmıyoruz; aslında arkamızda teknik bir kanıt ve güvenli bir operasyonel iz bırakıyoruz. Ekiplerinizin hem başını ağrıtmayacak hem de denetimlerde (audit) ellerini güçlendirecek, benim de bizzat sahada uyguladığım o pratik yaklaşımı şöyle özetleyebilirim:

Adım 1: Masayı Temizleyelim (Önce Güvenlik)
İşe başlamadan önce “Kim ne bırakmış?” diye bakmak, profesyonelliğin ilk adımıdır. Önceki analizlerden kalan filtreleri temizleyerek tertemiz bir sayfa açıyoruz:

pktmon filter list    # Mevcut filtreleri sorgula
pktmon filter remove --all  # Masayı temizle
pktmon list           # Donanımı tanı

Büyük ekiplerde en sık gördüğüm hata şu: bir önceki analistin bıraktığı filtrelerin farkında olmadan üzerine yazmak. Bu üç komutla önce masayı temizleyin, sonra neler olduğunu görün.

Adım 2: Nokta Atışı Yakalama (Samanlıkta İğne Aramayın)
Sunucuyu yormaya, logları şişirmeye gerek yok. Sadece soruna odaklanalım; örneğin sadece SQL trafiğini (1433) ve sadece fiziksel kartlarımızı (nics) takibe alalım:

pktmon filter add -p 1433 -t TCP
pktmon start --capture --comp 1

Tüm trafiği değil, sadece ilgilendiğiniz trafiği yakalayın. Bu basit odaklanma, log boyutunuzu çoğu senaryoda dramatik biçimde küçültür.

Önemli Uyarı: Yukarıdaki --comp 1 değeri sadece bir örnek. Kendi sisteminizde doğru bileşen ID’sini mutlaka pktmon list çıktısından kontrol edin.

Adım 3: Karmaşadan Kaçının, Pratik Yolu Seçin

pktmon list
# Çıktıdaki fiziksel NIC ID'sini bulun, veya tüm fiziksel NIC'leri doğrudan izlemek için:
pktmon start --capture --comp nics

Ekibime her zaman şunu söylerim: “Karmaşık listelerle uğraşmayın, doğrudan --comp nics kullanın.” Bu parametre, fiziksel katmana odaklanmanızı sağlar ve hata riskini sıfıra indirir.

Adım 4: Üretimde Güvenli Çalışın, Riske Girmeyin
Sunucu tarafında en büyük korkumuz disk dolmasıdır. Gelin bu riski “Circular Log” moduyla sıfıra indirelim. Log boyutu dolduğunda sistem en eski verinin üzerine yazsın, sunucumuz nefes almaya devam etsin:

pktmon start --capture --file-size 500 --mode circular

Burada liderlik kararınız devreye giriyor: --mode circular. Bu, sunucunuzun disk dolması nedeniyle çökmesini engelleyen hayati bir güvenlik önlemi.

Adım 5: Kök Nedeni Bulun ve Kanıtlayın
İşte zurnanın zırt dediği yer burası. “Network yavaş” diyenlere karşı elimizdeki en büyük koz:

pktmon counters

Bu komut, ağ bileşenlerinizde kaç paketin işlendiğini, iletildiğini veya düştüğünü gösterir. Anormal bir artış gördüğünüzde, sorunun tam yerini bulmuşsunuz demektir.

Bu sayaçlar ve yakalanan loglardaki Drop Reason alanı, size sadece paketin düştüğünü değil, nedenini de söyler. Örneğin, sorunun bir firewall politikası engellemesi mi, yoksa bir MTU uyuşmazlığı mı olduğunu doğrudan ayırt edebilirsiniz. Bu ayrım, sorun giderme sürenizi saatlerden dakikalara indirir.

Teknik Detay: Sayaçları sıfırlamak için pktmon counters --reset kullanabilirsiniz ama şunu unutmayın – bu parametrenin destek durumu Windows sürümüne göre değişebilir. Bu nedenle prod ortamda önce parametresiz çalıştırıp mevcut durumu gözlemlemek en güvenli yaklaşımdır.

pktmon stop
pktmon etl2pcapng PktMon.etl -o Olay_Kaniti.pcapng

Şimdi dikkat: Beyler, bu .pcapng dosyası bizim kara kutumuzdur ve hassas veriler içerir. Bu yüzden analizi asla üretim sunucusunda yapmıyoruz. Dosyayı alıp, internetten izole edilmiş, güvenliği sıkılaştırılmış “Güvenli Yönetim İstasyonu”muzda inceleyelim. Hem KVKK/GDPR uyumluluğumuzu koruyalım hem de verimizi sızıntı riskine karşı sağlama alalım.

Windows Server 2025: Mevcut Durum ve Gelişen Yönelimler

Windows Server 2025, artık erken benimseyen kurumların ve kontrollü üretim senaryolarının bir parçası haline geldi. Bu da, ağ teşhisini reaktif bir araç olmaktan çıkarıp proaktif bir operasyonel zekaya dönüştürme yolundaki adımların somutlaştığı anlamına geliyor.

Şu an gözlemlediğim ve heyecanla takip ettiğim yönelimler:

• Merkezi ve Proaktif Analiz Yönelimi: Pktmon çıktılarının Azure Arc üzerinden merkezi log analytics platformlarına daha derin entegrasyon potansiyeli, farklı lokasyonlardan gelen ağ telemetrisini tek bir noktadan analiz etme imkanı sunabilir.

• Hibrit Bağlantı Görünürlüğü: Geliştirmelerin, şirket içi sunucular ile Azure sanal ağları (VNet) arasındaki karmaşık bağlantı sorunlarının giderilmesine odaklandığı gözlemleniyor.

• Optimize Edilmiş Performans: Yeni nesil çekirdek iyileştirmeleri ile yüksek trafikli ortamlarda bile izlemenin performans üzerindeki etkisinin minimuma indirilmesi hedeflenmektedir.

BT Liderleri İçin Stratejik Karar Tablosu

Microsoft’un bize sunduğu en değerli operasyonel hediyelerden biri

Gerçek teknoloji liderliği, en pahalı aracı satın almak değil, elinizdeki envanterin gücünü sonuna kadar kullanabilmektir. Pktmon, çoğu kurumda hâlâ potansiyelinin çok altında kullanılan nadir yerleşik araçlardan biri.

İronik olan şu ki, bu yerleşik ve güçlü yetenek, bugün birçok kurumda hâlâ dışarıdan satın alınan pahalı araçlara veya vendor desteğine devredilmiş durumda.

Bu hafta içinde yapmanızı istediğim iki stratejik hamle:

1. SOP’nizi (Standart Operasyon Prosedürü) Güncelleyin: Kritik seviye (P1/P2) ağ sorunlarında pktmon counters komutunun çalıştırılmasını ve --mode circular parametresinin kullanımını, olay yönetimi sürecinize zorunlu bir adım olarak ekleyin.

2. Ekibinizin Yetkinliğini Geliştirin: Bu makaleyi ekibinizle paylaşın ve güvenli bir laboratuvar ortamında bu 5 adımlı iş akışını bir tatbikat olarak çalıştırın. Amacınız komut ezberletmek değil, “drop reason” okuma ve güvenli analiz istasyonu kullanma becerisi kazandırmak olsun.

Sizin bu konudaki deneyimleriniz neler? Ekibinizde Pktmon’u nasıl konumlandırıyorsunuz? Bu yetkinliği içeride mi geliştiriyorsunuz yoksa hala dış kaynağa mı bağımlısınız? Deneyimlerinizi yorumlarda paylaşalım, kolektif bilgimizi büyütelim.

Not: Bu makale, 16 Aralık 2025 itibarıyla güncel Windows Server sürümleri ve resmi Microsoft dokümantasyonu referans alınarak hazırlanmıştır. Üretim ortamınızda büyük çaplı değişiklik yapmadan önce, her zaman test ortamınızda doğrulama yapmanız önemle tavsiye edilir.