Kurumsal Sunucu İzleme: 12 Kritik Metrik ve Alarm Planı

Kurumsal sunucu izleme, bir Windows veya Linux sunucusunun yalnızca açık olup olmadığını kontrol etmek değildir. SQL Server hizmeti durmuş, disk yanıtları yavaşlamış veya gece çalışan yedekleme başarısız olmuşken sunucu ping isteğine yanıt vermeye devam edebilir. ERP, dosya paylaşımı, uzak masaüstü ve e-ticaret kullanan şirketler için doğru sunucu izleme hizmeti, kullanıcıyı etkileyen olayları erken fark edip sorumlu ekibe doğru alarmı ulaştırmalıdır.

Kısa cevap: Sağlıklı bir izleme planında servis erişilebilirliği, yanıt süresi, hata oranı, trafik, CPU, RAM, disk doluluğu, disk gecikmesi, ağ kalitesi, veritabanı sağlığı, yedekleme ve sertifika/izleme ajanı durumu birlikte değerlendirilmelidir. Her metrik için ölçüm kaynağı, zaman penceresi, iş etkisi, uyarı sahibi ve müdahale yöntemi yazılı olmalıdır. Herkese aynı sabit yüzdeyi uygulamak doğru değildir.

Bu rehber; BT yöneticilerine, kendi sunucusunu işleten KOBİ'lere ve yönetilen sunucu hizmetleri için teklif hazırlayan satın alma ekiplerine yöneliktir. Buradaki örnek uyarılar bağlayıcı bir SLA veya belirli bir sağlayıcının sunduğu garanti değildir; gerçek sınırlar ölçüm ve sözleşmeyle doğrulanmalıdır.

1. Sunucu izleme neden sadece ping ve CPU grafiği değildir?

Bir sunucunun ICMP yanıtı vermesi ağ üzerinden ulaşıldığını gösterebilir; ancak uygulamanın kullanılabilir olduğunu doğrulamaz. Kullanıcı giriş ekranı açılırken SQL bağlantısı kopabilir, dosya paylaşımı izin hatası verebilir veya ödeme entegrasyonu çalışmayabilir. Bu nedenle altyapı, servis ve gerçek iş akışı farklı seviyelerde ölçülmelidir.

Google'ın SRE izleme rehberi, kullanıcıya dönük hizmetler için dört temel sinyal tanımlar: gecikme, trafik, hatalar ve doygunluk. CPU ve RAM bu resmin yalnızca kapasite kısmıdır. Gecikme ile hata oranını birlikte görmek, iş etkisi olan arızayı gereksiz alarm gürültüsünden ayırır.

İlk adım, şirketin kritik süreçlerini yazmaktır: muhasebe fişi kaydı, ERP raporu, şirket dosyasına erişim, Microsoft 365 kimlik doğrulama bağımlılığı veya web siparişi. İzlemenin başarısı sunucu sayısına değil, bu işlemlerin gerçekten doğrulanabilmesine göre değerlendirilmelidir.

2. Kritik metrik 1: Servis ve iş akışı erişilebilirliği

Sunucu çalışıyor ile hizmet çalışıyor farklı durumlar olabilir. Ağ kontrolüne ek olarak HTTP/TCP servis denetimi, Windows hizmeti veya Linux systemd durumu, veritabanına basit bağlantı ve uygun bir sentetik kullanıcı akışı izlenebilir. Sadece HTTP 200 almak, yanlış içerik sunan uygulamanın sağlıklı olduğu anlamına gelmeyebilir.

Örneğin müşteriye açık web sitesinde sayfanın gerçek başlığının veya belirli işlevin doğrulanması; yalnız ana sayfanın cevap vermesinden daha güçlü bir kontroldür. ERP ortamında ise üretici desteğine uygun, veriyi değiştirmeyen bir servis sağlık testi tercih edilmelidir.

Alarm şartı tek bir başarısız sorgu yerine tekrarlı test veya birbirinden bağımsız ölçümle doğrulanabilir. Ancak kritik sistemde uzun doğrulama penceresi seçmek de olayı geç fark etmeye yol açabilir. Tolerans, işin gerekliliğine göre ayarlanmalıdır.

3. Kritik metrik 2: Yanıt süresi ve kullanıcı gecikmesi

Uygulama gecikmesi ağ, web servisi, veritabanı, disk veya istemci kaynaklı olabilir. Ortalama yanıt süresi bazı sorunları gizleyebilir; özellikle p95 veya p99 gibi yüzdelik dilimler, kullanıcıların en yavaş deneyimlerini görünür kılar. Başarısız isteklerin gecikmesini başarılarla karıştırmadan ayrı değerlendirmek gerekir.

Örneğin bir ERP raporunun sabah hızlı, yoğun mesai saatinde yavaş olması; gün boyu tek ortalama alınarak görülemeyebilir. Örnekleme periyodunu, kullanıcı ve rapor sınıfını, sistem üzerindeki yoğunluğu aynı grafikte karşılaştırın.

Teklifte “uygulama yanıt süresi de izleniyor mu, yoksa yalnız sunucu kaynakları mı?” diye sorun. İzlemenin kullanıcı deneyimine uzanıp uzanmadığı, operasyon hizmetinin gerçek kapsamını gösterir.

4. Kritik metrik 3: Hata oranı ve başarısız işlemler

HTTP 5xx, bağlantı reddi, SQL oturum hatası, kuyrukta biriken işlem veya zaman aşımı gibi sinyaller kullanıcı etkisini gösterebilir. Ancak her HTTP 4xx sunucu arızası değildir; örneğin beklenen yetki reddiyle uygulama hatasını ayrı sınıflandırın.

Hata adedini yalnız toplam sayı olarak değil istek veya işlem sayısına oranla izlemek yararlıdır. Dakikada yüzlerce istek alan servisle birkaç işlem yapan arka ofis uygulamasına aynı adet eşiği uygulanamaz. Hata artışından önceki dağıtımı, bakım işlemini veya ağ değişikliğini de olay kaydına ekleyin.

Yanlış pozitifleri azaltmak için kritik iş işlemlerindeki başarısızlığı ayrı alarm konusu yapın. Gerçekten kullanıcı etkisi olan hata, yalnız log dosyasındaki rastgele bir uyarıdan daha yüksek öncelik taşımalıdır.

5. Kritik metrik 4: Trafik, iş yükü ve eşzamanlı oturum

Ağda saniyelik megabit kullanımı, web tarafında istek sayısı, RDS ortamında etkin oturum, SQL tarafında işlem ve bağlantı sayısı farklı talep göstergeleridir. Sunucu yoğunlaşmadan önce talebin neden arttığını anlamak kapasite planını iyileştirir.

Örneğin ay sonunda muhasebe raporlarının artması ile olağan dışı trafik sıçraması aynı müdahaleyi gerektirmez. Zaman çizelgesinde bakım, kampanya, şube bağlantısı ve planlı iş başlangıçlarını kaydedin. Böylece öngörülebilir iş yüklerini arıza gibi değerlendirme ihtimali azalır.

Kapasite toplantısında en yoğun saat, ortalama saat ve değişken talep profilleri ayrı gösterilmelidir. Yalnız aylık toplam trafik grafiği, kısa süren darboğazları açıklamak için yeterli değildir.

6. Kritik metrik 5: CPU kullanımı ve işlemci beklemesi

CPU kullanımında ortalamanın yanında yüksek tüketimin ne kadar sürdüğü önemlidir. Tek bir işlemcide aşırı yük görülürken toplam CPU grafiği makul görünebilir. Windows'ta işlemci sayaçları ve bekleme kuyruğu; Linux'ta kullanıcı/sistem CPU zamanı, yük ve uygun sanallaştırma metrikleri birlikte incelenebilir.

Microsoft'un Windows Performance Monitor rehberi, CPU, bellek, disk ve ağ sayaçlarının zaman içinde kaydedilerek darboğaz araştırılmasını önerir. VPS kullanımında varsa CPU steal time, ana makinedeki rekabet hakkında ek sinyal sağlayabilir; tek başına kesin neden değildir.

“CPU yüzde 80'e ulaştı” gibi evrensel bir alarm yerine, uygulamanın normal davranışı, yoğun saat ve yanıt süresindeki bozulma birlikte değerlendirilmelidir. Donanımı büyütmeden önce hatalı süreç, sorgu veya planlı iş olup olmadığını kontrol edin.

7. Kritik metrik 6: RAM baskısı, paging ve swap

RAM kullanım oranının yüksek olması her zaman bellek yetersizliği anlamına gelmez. İşletim sistemi önbelleği, SQL Server buffer pool ve uygulamaların bellek yönetimi toplam kullanım grafiğini etkiler. Asıl önemli işaretler kullanılabilir bellek düşüşü, sürekli paging/swap, bellek tahsis hatası ve uygulama gecikmesidir.

Windows'ta Available MBytes, Pages/sec gibi sayaçlar; Linux'ta kullanılabilir bellek, swap etkinliği ve bellek baskısı göstergeleri izlenebilir. Kısa süreli yük ile sürekli baskıyı ayırmak gerekir. Otomatik RAM yükseltmesi her zaman uygulamanın gerçek sorununu çözmez.

Kullanıcı oturumları, antivirüs taraması ve veritabanı servisleri aynı makinede çalışıyorsa ölçümün hangi bileşenden geldiği kaydedilmelidir. Teklifte kapasiteyi artırma sırasında kesinti gerekip gerekmediği de açıklanmalıdır.

8. Kritik metrik 7: Disk doluluğu ve büyüme hızı

Disk alanı alarmı yalnız yüzde doluluk üzerinden kurulursa büyük disklerde yanlış yönlendirebilir. Kalan kullanılabilir GB/TB ve son günlerdeki büyüme hızı birlikte değerlendirilmelidir. Linux dosya sistemlerinde inode tüketimi de bazı iş yükleri için önemlidir.

SQL transaction log, Windows güncelleme dosyaları, geçici raporlar, yedek klasörü veya beklenmedik log büyümesi üretim hizmetini durdurabilir. Kalan alanın mevcut büyüme hızında ne kadar süre dayanacağına ilişkin eğilim, tek bir sabit yüzde uyarısından daha açıklayıcı olabilir.

Prometheus'un Node Exporter belgelerinde dosya sistemi kullanılabilir alanı ve ağ/CPU metrikleri gibi sistem ölçümlerinin toplanabildiği gösterilir. Bu metrikler ajan erişim güvenliği ve saklama politikasıyla birlikte kullanılmalıdır.

9. Kritik metrik 8: Disk gecikmesi, IOPS ve I/O kuyruğu

Bir sunucuda disk boş alanı yeterliyken SQL veya ERP işlemleri yine de yavaşlayabilir. Okuma/yazma gecikmesi, IOPS, throughput ve sıra uzunluğu beraber değerlendirilmeli; farklı işlem türlerinin davranışı aynı sayıya indirgenmemelidir. Disk gecikmesiyle uygulamanın yanıt süresi arasındaki ilişki ayrıca incelenir.

Microsoft'un Windows Server performans incelemesi, disk okuma/yazma sayaçlarını; SQL Server'ın I/O sorun giderme rehberi ise bekleme istatistikleri ve dosya düzeyinde I/O ölçümünü birlikte ele alır.

SSD veya NVMe yazması olması, yoğun saatlerde belirli gecikme değerinin kesin garanti edildiği anlamına gelmez. Karar için gerçek uygulama yükü, ölçüm penceresi, paylaşımlı depolama koşulları ve üretici rehberi gerekir. SQL Server performans ve lisans rehberimiz bu teknik ayrımı açar.

10. Kritik metrik 9: Ağ gecikmesi, paket kaybı ve bağlantı hataları

Port hızı ile uçtan uca ağ kalitesi aynı şey değildir. ERP, uzak masaüstü veya dosya paylaşımı kullanan kurumlarda RTT gecikmesi, paket kaybı, yeniden iletim, interface hata sayısı ve bağlantı sürekliliği iş deneyimini etkileyebilir. Ölçümler mümkünse kullanıcıların gerçekten bağlandığı ağ noktalarından yapılmalıdır.

Bir bağlantı sorunu yalnız veri merkezinden çıkışta olmayabilir. Ofis firewall'ı, VPN tüneli, DNS, internet operatörü veya istemci kaynaklı gecikme de olasıdır. Tek noktadaki ping sonucundan hangi tarafın hatalı olduğunu kesin olarak çıkarmayın.

Ağ güvenliği ve VPN hizmetleri için tünel sağlığı, lisans/oturum sınırları, rota değişikliği ve alarm eskalasyonu hizmet tanımında yer almalıdır. Şubeler arası kritik bağlantılarda alternatif yol testi de operasyon planının parçası olabilir.

11. Kritik metrik 10: Veritabanı ve uygulama servislerinin sağlığı

SQL Server, ERP veya uygulama sunucusunda yalnız işlemciyi değil, kritik hizmetin gerçekten cevap verip vermediğini izlemek gerekir. SQL bağlantı başarısı, sorgu gecikmesi, kilitlenmeler, log büyümesi, bekleme sınıfları ve planlı iş hataları doğru kapsama göre değerlendirilebilir.

Bir veritabanı servisini ping ile doğrulamak yeterli değildir. Uygun yetkili, veriyi değiştirmeyen sağlık sorguları, uygulama üreticisinin desteklediği testler ve iş akışı kontrolleri tercih edilmelidir. Veritabanı kimlik bilgileri izleme araçlarına gereğinden fazla ayrıcalıkla verilmemelidir.

Logo, Mikro, Zirve ve SAP benzeri uygulamalarda sorgu optimizasyonu veya uygulama hatası her zaman altyapı sağlayıcısının sorumluluğunda değildir. Bu nedenle ERP ve muhasebe sunucu çözümleri için uygulama, veritabanı ve sunucu ekiplerinin görevlerini açıkça ayırın.

12. Kritik metrik 11: Yedekleme, son başarılı iş ve geri yükleme

Yedekleme işi başarılı görünmesi ile dosyanın gerektiğinde geri yüklenebilmesi farklı konulardır. Alarm planı son başarılı yedeğin zamanı, beklenen yedek sıklığı, yedek dosyasının bütünlüğü, hedef depolama durumu ve geri yükleme test sonuçlarını kapsamalıdır.

Kritik sistemlerde RPO, kabul edilebilir veri kaybı aralığını; RTO ise hedef hizmete dönüş süresini ifade eder. Bu hedefleri iş birimi belirlemeli; yedekleme ve kurtarma mimarisi bunlara göre test edilmelidir. Özellikle yalnız aynı sunucuda duran kopyalar, tüm tesisi etkileyen arızaya karşı yeterli kabul edilmemelidir.

Yedekleme ve felaket kurtarma hizmetlerini karşılaştırırken hangi işlerin otomatik izlendiğini, kimin gerçek geri yüklemeyi test ettiğini ve başarısız yedeklemede ilk kimin uyarıldığını yazılı isteyin.

13. Kritik metrik 12: Sertifika, DNS ve izleme sisteminin kendi sağlığı

Web uygulamalarında TLS sertifikasının son kullanım tarihi, DNS çözümlemesi, uygulama sertifika zinciri ve gerekli servis bağımlılıkları kesintiye yol açabilir. Bir HTTPS sertifikası yenilenmiş olsa bile uygulamaya doğru dağıtılmamışsa kullanıcı hatası devam edebilir.

Ayrıca izleme ajanının kendisi de izlenmelidir. Ajan durmuş, toplayıcı bağlantısı kopmuş veya ölçüm verisi güncellenmiyorsa “alarm yok” ifadesi “sistem sağlıklı” anlamına gelmez. Mümkünse merkezi izlemenin dışında ikinci bir erişilebilirlik doğrulaması uygulanabilir.

Sertifika ve DNS uyarılarını uygulama sahipliğiyle ilişkilendirin. Örneğin ödeme entegrasyonu veya dış API sertifikası kuruma ait değilse uyarı alınabilir; fakat düzeltme yetkisinin hangi tarafta olduğu önceden belirlenmelidir.

14. Alarm planı: 12 metriği nasıl uygulanabilir aksiyona dönüştürürüz?

Her metriğin alarm hâline gelmesi gerekmez. Pano (dashboard) soru sormayı; alarm sorumlu kişiye gerçek bir aksiyon başlatmayı sağlamalıdır. Google SRE yaklaşımı, kişiyi gereksiz yere uyandıran alarm gürültüsünün gerçek olayları gizleyebileceğini vurgular. Tekrarlı veya bağımlı alarmlar, aynı ana olaya bağlanmalıdır.

Bu koşullar örnek alarm mantığıdır, herhangi bir kuruma ait hazır yüzdelik eşik veya garanti değildir. Kritik ve düşük öncelikli bildirimleri ayırın, alarmın tekrarlanma sınırını belirleyin, bakım pencerelerini tanımlayın ve olay sonrası yanlış uyarıları gözden geçirin.

15. Yönetilen sunucu izleme teklifinde neler yazmalı?

Teklifte izlenen sistem ve servis envanteri, metrik listesi, veri saklama süresi, panoya erişim, uyarı kanalları, mesai dışı bildirim, müdahale yetkisi, bakım penceresi ve aylık raporlama kapsamı yazmalıdır. Sadece “7/24 izleme” denmesi, bir mühendisin her alarma anında müdahale edeceği anlamına gelmez.

Özellikle ilk yanıt süresi, müdahale başlangıcı ve çözüm hedefi birbirinden ayrılmalıdır. Veri merkezinin ağ/donanım sorumluluğu, işletim sistemi yönetimi, SQL bakımı ve ERP üreticisinin desteği ayrı katmanlardır. Bir arıza yalnızca loglara kaydedilmişse ve kimse aksiyon almıyorsa izleme iş değerini tam karşılamaz.

Teklif değerlendirmesinde şu soruları yanıtlatın: Alarmlar hangi iş sürecine bağlı, ilk bildirim kime gidiyor, müdahale dışında kalan işlemler neler, yedek testi kimin görevi, aylık raporda hangi eğilimler gösteriliyor? Yönetilen sunucu kiralama ve bakım kapsamını bu sorularla birlikte karşılaştırabilirsiniz.

16. Sunucu izleme hizmeti için teknik keşif ve teklif talebi

İlk görüşmede mevcut Windows/Linux sunucu sayısını, sanal veya fiziksel kaynak modelini, kritik uygulamaları, şube bağlantılarını, yedek ürünlerini ve iş saatlerini paylaşın. Her sistem için kimlerin etkilendiğini, kabul edilebilir kesintiyi ve olay anında erişilecek yetkili kişileri belirleyin.

Sunucu izlemeyi yeni bir VPS veya dedicated hizmetiyle birlikte alacaksanız ağ izolasyonu, ölçüm ajanı güvenliği ve rol bazlı erişimi de kapsama dahil edin. VPS/bulut sunucu ile dedicated sunucu kiralama farklı kaynak modelleridir; iki teklifin izleme ve müdahale kapsamını aynı tablo üzerinden karşılaştırın.

Netsun Bilişim ile teknik ihtiyaç analizi için kurumsal sunucu izleme ve yönetim teklifi alın. İstenen alarm, yedekleme, kapasite ve operasyon kapsamı, ölçülmüş iş yüküne göre netleştirildiğinde daha anlamlı bir hizmet teklifi hazırlanabilir.

Sık sorulan sorular

1. Sunucu izleme hizmeti yalnız CPU ve RAM'i mi kontrol eder?

Hayır. Servis erişilebilirliği, uygulama yanıtı, hata oranı, disk alanı ve gecikme, ağ, veritabanı, yedekleme ve kritik sertifikalar da izlenebilir. Hangi kontrolün gerçekten sunulduğu sözleşmede belirtilmelidir.

2. Ping yanıtı veren bir sunucu neden çalışmıyor olabilir?

İşletim sistemi ağ yanıtı verirken SQL, web servisi, ERP uygulaması veya kimlik doğrulama bileşeni durmuş olabilir. Bu nedenle sunucuya erişim testi, uygulama ve gerçek iş akışı denetiminin yerine geçmez.

3. CPU veya RAM için evrensel alarm eşiği var mı?

Tek bir sayı her iş yükü için doğru değildir. Baz değer, yoğun saat, kaynak baskısının süresi ve kullanıcıya etkisi birlikte değerlendirilmelidir. Kısa ve normal yük artışları için gereksiz gece alarmı üretmek doğru değildir.

4. Windows Server ve Linux sunucu aynı araçla izlenebilir mi?

Merkezi bir izleme sistemi her iki platformdan veri toplayabilir, ancak ajanlar ve ölçüm kaynakları farklıdır. Windows Performance Monitor, Linux Node Exporter veya uyumlu diğer yöntemlerin erişim ve güvenlik koşulları ayrıca planlanır.

5. Başarılı yedekleme alarmı geri yükleme garantisi verir mi?

Hayır. Dosya bütünlüğü, depolama erişimi, uygulama tutarlılığı ve gerçek geri yükleme testi ayrı doğrulama konularıdır. RPO/RTO hedefleri ancak uygun senaryo testleriyle değerlendirilebilir.

6. 7/24 sunucu izleme ile 7/24 müdahale aynı hizmet mi?

Hayır. Otomatik ölçüm ve bildirim sürekli çalışabilir; ancak mühendis müdahalesinin saatleri, ilk yanıt, kapsam ve uygulama desteği ayrıca sözleşmede tanımlanmalıdır. Sağlayıcının gerçek yükümlülükleri açık olmalıdır.

7. Kurumsal sunucu izleme fiyatı nasıl belirlenir?

İzlenecek sistem sayısı, uygulama ve metrik kapsamı, veri saklama, alarm kanalları, destek saatleri, operasyon yetkisi ve raporlama maliyeti etkiler. Farklı teklifleri ancak aynı sorumluluk ve hizmet kapsamıyla karşılaştırmak gerekir.

Resmî teknik kaynaklar ve sonuç

Bu rehberdeki yöntemler Google SRE - Monitoring Distributed Systems, Prometheus Node Exporter rehberi, Microsoft Windows Server Performance Monitor ve Microsoft SQL Server I/O sorun giderme belgelerinden yararlanılarak hazırlanmıştır. Ölçüm eşikleri ve destek kapsamı her kurumun gerçek sistemiyle ayrıca doğrulanmalıdır.

Sonuç: Kurumsal sunucu izleme, daha fazla grafik veya daha çok bildirim üretme işi değildir. Esas değer, gerçek kullanıcı etkisini ölçmek, önemli arızayı erken fark etmek ve doğru ekibin aksiyon almasını sağlamaktır. Sunucu izleme ve yönetilen hizmet teklifi alın ve 12 kritik metriği teknik keşifte ortak kontrol listesi olarak kullanın.