Sunucu İzleme: Hangi Metrikler, Hangi Eşik Değerleri?

İzleme aracını kurmak bir öğleden sonra sürer. Zor olan, sorun büyümeden uyaran ama gece üçte kimseyi boş yere uyandırmayan bir alarm kurgusudur. Çoğu ortamda araç çalışır, e-posta kutusu alarmla dolar ve gerçek arıza o gürültünün içinde kaybolur. Windows ve Linux sunucularda hangi metriğin gerçekten bir şey söylediği, iki platformdaki karşılık sayaçları ve eşiklerin sabit sayı yerine sunucunun kendi davranışından nasıl çıkarılacağı aşağıda.

İzlemenin amacı: arıza, performans, kapasite

Her metrik üç sorudan birine yanıt verir. Hangisine yanıt verdiği, alarmın aciliyetini ve kimin ilgileneceğini belirler:

• Arıza: Hizmet şu anda çalışıyor mu? (Hizmet durumu, port yanıtı, disk dolu, RAID degrade.) Anında müdahale ister.
• Performans: Hizmet çalışıyor ama kullanıcı yavaşlık yaşıyor mu? (Disk gecikmesi, CPU kuyruğu, bellek baskısı.) Saatler içinde incelenir.
• Kapasite: Bu eğilimle kaynak ne zaman bitecek? (Disk büyüme hızı, ortalama CPU artışı.) Haftalık veya aylık raporla yönetilir; alarm değil, plan konusudur.

Sahada en sık gördüğümüz hata, kapasite metriğini arıza alarmı gibi kurgulamaktır. “Disk yüzde 80 doldu” e-postası her sabah gelir, bir hafta sonra kimse açmaz, disk gerçekten dolduğunda da fark edilmez. Okunmayan alarm, alarm değildir.

Temel metrikler ve anlamları

CPU

Yüksek CPU kullanımı tek başına arıza değildir; derleme veya yedek sıkıştırma sırasında tüm çekirdeklerin dolması beklenen davranıştır. Asıl sinyal işlemci kuyruğudur: çalışmaya hazır ama CPU bekleyen iş parçacıkları. Windows’ta \System\Processor Queue Length değerinin çekirdek sayısının yaklaşık iki katını sürekli aşması, Linux’ta vmstat çıktısındaki r sütununun çekirdek sayısını kalıcı olarak geçmesi CPU darboğazıdır. Sanal makinede ayrıca hipervizör beklemesine bakın: Linux’ta %steal, VMware’de CPU Ready. Bunlar yüksekse sorun misafir işletim sisteminde değil, host’taki sıkışıklıktadır. VM’e vCPU eklemek bu durumda işi kötüleştirebilir. Boyutlandırma tarafı vCPU, bellek ve NUMA boyutlandırma yazısında.

Bellek

“Kullanılan bellek” sayısı yanıltır; hem Windows hem Linux sunucular boş belleği dosya önbelleği için kullanır. İzlenecek olan, uygulamaya hemen verilebilecek bellek (Windows’ta Available MBytes, Linux’ta free çıktısındaki available) ve sayfalamanın gerçekten diske gidip gitmediğidir. Windows’ta % Committed Bytes In Use değerinin commit limitine yaklaşması, sayfa dosyası büyüse bile uygulamaların bellek ayıramayacağı noktaya gidildiğini gösterir. Linux’ta vmstat içindeki si/so (swap in/out) sütunlarının sürekli sıfırdan farklı olması gerçek bellek baskısıdır. Swap alanının bir kısmının dolu durması değildir.

Disk

Disk tarafında en çok şey söyleyen metrik gecikmedir, yani her G/Ç işleminin ortalama süresi. Doluluk oranı arıza ve kapasite metriği, gecikme performans metriğidir. Sahada yaygın başlangıç yorumu: okuma/yazma gecikmesi 10 ms altında iyi, 10–20 ms arasında izlenmeli, 20 ms üzerinde sürekli ise kullanıcı hisseder. SSD/NVMe tabanlı depolamada beklenen değer milisaniyenin altındadır; orada birkaç milisaniyelik kalıcı gecikme bile anormaldir. Kuyruk uzunluğunu tek başına yorumlamayın. Modern depolama dizileri derin kuyrukla verimli çalışır; kuyruk ancak gecikmeyle birlikte yükseliyorsa anlamlıdır.

Ağ

Sunucu tarafında arayüz kullanım oranı, hatalı ve atılan paketler ve çıkış kuyruğu izlenir. Atılan paket sayacı artıyorsa sebep çoğu zaman bant genişliği değil; sürücü, offload ayarı veya switch portunda hız/dupleks uyumsuzluğudur. Önce sürücü sürümüne ve port ayarına bakın. Ağ cihazlarının kendi izlenmesi ayrı bir konu; araç seçimi için Zabbix, LibreNMS ve PRTG karşılaştırması yol gösterir.

Windows ve Linux sayaç karşılıkları tablosu

Windows’ta Avg. Disk sec/Read saniye cinsindendir; 0,015 değeri 15 ms demektir. Birimi milisaniye sanan bir pano gecikmeyi “sıfır” gösterir. Linux’ta iostat sütun adları sysstat sürümüne göre değişir (eski sürümlerde await ve avgqu-sz). Inode tükenmesi de diski “dolu” gösterir; df -h boş alan gösterirken yazma hatası alıyorsanız ilk bakılacak yer df -i’dir. Çok sayıda küçük dosya üreten sunucularda bunu ayrıca izleyin.

Eşik belirleme ve baseline

Statik eşik (“CPU yüzde 90 üstü alarm”) her sunucuda aynı anlama gelmez. Gece toplu iş çalıştıran uygulama sunucusunda bu değer normaldir; bir etki alanı denetleyicisinde anormaldir. Baseline yaklaşımı önce sunucunun normalini ölçer, sonra sapmayı alarm konusu yapar.

Uygulama sırası:

1. En az iki–dört hafta boyunca bir dakikalık çözünürlükte veri toplayın; ay sonu veya bordro gibi dönemsel yükleri kapsayacak kadar uzun tutun.
2. Her metrik için saat ve gün bazında 95. persentili hesaplayın. Pazartesi 09:00 ile pazar 03:00’ün normali aynı değildir.
3. Uyarı eşiğini baseline’ın üzerine, kritik eşiği donanımın veya hizmetin fiziksel sınırına yakın koyun.
4. Süre koşulu ekleyin: tek ölçüm değil, örneğin “son 5 ölçümün 4’ünde” eşik aşımı.

Windows’ta izleme aracından bağımsız bir baseline kaydını logman ile başlatabilir, anlık kontrolü Get-Counter ile yapabilirsiniz:

# PowerShell: 60 saniye aralıkla CSV'ye yazan sayaç kümesi
logman create counter Baseline -si 00:01:00 -f csv -o "C:\PerfLogs\Baseline" -c `
  "\Processor(_Total)\% Processor Time" "\System\Processor Queue Length" `
  "\Memory\Available MBytes" "\LogicalDisk(*)\Avg. Disk sec/Read" `
  "\LogicalDisk(*)\Avg. Disk sec/Write"
logman start Baseline

# Anlık kontrol: 5 saniye aralıkla 12 örnek
Get-Counter -Counter "\LogicalDisk(*)\Avg. Disk sec/Write" -SampleInterval 5 -MaxSamples 12

Linux’ta sysstat paketi kurulup etkinleştirildiğinde sar geçmiş veriyi günlük dosyalara yazar. Anlık inceleme için:

vmstat 5 6          # 5 saniye aralıkla 6 örnek; ilk satır açılıştan beri ortalamadır
iostat -x 5 3       # aygıt bazında gecikme ve kuyruk
sar -n DEV 5 3      # arayüz bazında trafik

vmstat ve iostat çıktısındaki ilk rapor açılıştan bu yana ortalamadır. Anlık durum için ikinci ve sonraki satırlara bakın. Arıza anında en sık yapılan okuma hatası budur.

Alarm yorgunluğunu önleme

Alarm yorgunluğu, ekibin alarmları okumayı bırakmasıyla biter; izleme sistemi çalışır ama fiilen devre dışıdır. Bunu önleyen kurallar:

• Her alarm bir eylem gerektirmeli: Alarmı alan kişi ne yapacağını bilmiyorsa ya alarm gereksizdir ya da yanında kısa bir müdahale notu (runbook) eksiktir.
• Bağımlılık tanımı: Şube switch’i düştüğünde arkasındaki on sunucu için on ayrı alarm üretilmemeli; üst bağımlılık alarmı alt alarmları bastırmalı.
• Histerezis: Kapanma eşiği açılma eşiğinden düşük olmalı; aksi halde eşik çevresinde dalgalanan metrik sürekli aç-kapa üretir.
• Önem seviyesi ve yönlendirme: Kritik alarm nöbetçiye anlık bildirim, uyarı seviyesi mesai içi kuyruk, bilgi seviyesi yalnız rapor.
• Bakım penceresi: Planlı yama ve yeniden başlatmalarda alarmlar susturulmalı; bunun için yama takvimi izleme sistemine işlenmeli. Süreç tasarımı için sunucu yama yönetimi yazısına bakın.
• Düzenli ayıklama: Ayda bir, en çok tetiklenen alarmları açın; eşiği, süre koşulunu ya da alarmın varlığını sorgulayın.

Uygulama ve hizmet düzeyi kontroller

Kaynak metrikleri yeşilken hizmet çalışmıyor olabilir. CPU, bellek ve disk normal; ama IIS uygulama havuzu durmuş, kullanıcı hata sayfası görüyor. Bu yüzden kaynak izlemenin üstüne bir hizmet katmanı gerekir:

• Otomatik başlatılacak şekilde ayarlı ama çalışmayan Windows hizmetleri; Linux’ta systemctl --failed çıktısı.
• Port ve protokol kontrolü: yalnız TCP bağlantısı değil, HTTP yanıt kodu, LDAP sorgusu veya SQL oturumu gibi gerçek bir işlem.
• TLS sertifika bitiş tarihleri; bitişten haftalar önce uyarı.
• Olay günlüğü kalıpları: Windows’ta beklenmeyen kapanma (System günlüğünde 6008 ve Kernel-Power 41), disk G/Ç yeniden denemeleri (153); Linux’ta journalctl -p err ve dmesg içinde G/Ç hataları.
• Donanım: RAID durumu, güç kaynağı ve fan uyarıları üretici yönetim kartı (iDRAC, iLO, XClarity gibi) üzerinden SNMP veya Redfish ile.
• Yedekleme işlerinin sonucu ve son başarılı yedeğin yaşı.

Kapasite eğilim raporu

Kapasite raporu alarmlardan ayrı, aylık üretilen ve sunucu ve sistem altyapısı için karar aldıran bir dokümandır. Her sunucu ve birim için mevcut kullanım, son 30 ve 90 günlük ortalama artış hızı ve bu hızla kaynağın tükeneceği tahmini tarih yer alır. Disk için hesap basittir:

Örnek hesap: 500 GB’lık bir veri biriminde 380 GB dolu ve son 90 günün ortalama artışı günde 1,5 GB ise kalan 120 GB yaklaşık 80 gün içinde tükenir. Bu süre satın alma ve devreye alma sürenizden kısaysa genişletme bugün planlanmalıdır. Linux sunucularda uygulama adımları LVM ile disk genişletme yazısında.

Raporda üç eğilime ayrıca bakın: mesai saatlerindeki 95. persentil CPU değerinin aylar içinde yükselmesi, kullanılabilir belleğin taban değerinin düşmesi ve disk gecikmesinin yük artmadan kötüleşmesi. Sonuncusu genellikle kapasite değil, depolama tarafında bir arızadır: bozulmaya başlayan disk, dolmaya yakın havuz, yanlış önbellek ayarı. Yük sabit, gecikme artıyorsa donanıma bakın.

İzleme metriklerinin periyodik bakım görevleriyle birlikte nasıl ele alınacağı sunucu bakım kontrol listesi yazısında. İzleme kurgusunun tasarımı ve sürekli işletimi teknik destek ve periyodik bakım hizmetinin kapsamındadır. Windows sayaçlarının sözdizimi için temel kaynak Microsoft Learn’deki Get-Counter belgesidir.

Sık sorulan sorular

CPU kullanımı için hangi eşik değeri kullanılmalı?

Evrensel bir değer yoktur. CPU kullanımını işlemci kuyruğu ve süre koşuluyla birlikte değerlendirin, eşiği her sunucunun kendi baseline verisine göre koyun. Yüksek kullanım kuyruk oluşturmuyorsa çoğu zaman sorun değildir.

Disk gecikmesi hangi değerde sorun sayılır?

Döner diskli sistemlerde 10 ms altı iyi, 20 ms üzerinde sürekli gecikme kullanıcı tarafından hissedilir kabul edilir. SSD ve NVMe depolamada beklenen değer milisaniyenin altındadır; birkaç milisaniyelik kalıcı gecikme bile incelenmelidir.

Linux’ta bellek neredeyse dolu görünüyor, sorun var mı?

Büyük olasılıkla hayır. Linux boş belleği dosya önbelleği için kullanır. free çıktısındaki available değeri yeterliyse ve vmstat içindeki si/so sütunları sürekli sıfırdan farklı değilse bellek baskısı yoktur.

Baseline için ne kadar süre veri toplamak gerekir?

En az iki ile dört hafta. Ay sonu kapanışı, bordro veya dönemsel raporlar gibi tekrarlayan yükleri kapsayacak bir dönem seçin ve baseline’ı yılda en az bir kez yenileyin.