Sunucu izleme (monitoring), sunucularınızın ve üzerinde çalışan kritik servislerin sağlığını CPU, bellek (RAM), disk, ağ ve servis durumu gibi metrikler üzerinden sürekli ölçen, belirlenen eşikler aşıldığında ekibi otomatik olarak uyaran sistematik bir BT yönetim pratiğidir. Amacı basit ama belirleyicidir: bir sorunu kullanıcılar fark etmeden, hatta sistem tamamen durmadan önce yakalamak. İzleme olmadan BT yönetimi “tepkisel” (sistem çöktükten sonra müdahale) kalır; izleme ile birlikte “proaktif” (sorun büyümeden önce müdahale) hale gelir. Bu yazıda, Gaziantep ve çevresindeki kurumsal işletmeler için izlenmesi gereken metrikleri, alarm kurgusunu ve proaktif müdahale yaklaşımını adım adım ele alıyoruz.
Sunucu izleme neden gereklidir?
ERP veritabanınız yavaşladığında, e-fatura servisiniz yanıt vermediğinde veya disk dolduğu için sistem çöktüğünde işletme fiilen durur. Bu olayların neredeyse tamamı önceden uyarı sinyali verir: disk yavaşça dolar, bellek aylar içinde tükenir, bir servis defalarca yeniden başlar. İzleme bu sinyalleri yakalar.
İzlemenin somut faydaları şunlardır:
- Erken uyarı: Disk %90 dolduğunda alarm alırsınız; %100 olup sistem çökmeden önce müdahale edersiniz.
- Kök neden analizi: Bir yavaşlamanın CPU mu, disk I/O mu, yoksa ağ mı kaynaklı olduğunu tahmin ederek değil, ölçerek bilirsiniz.
- Kapasite planlama: Aylar içindeki büyüme eğilimini görerek donanım yatırımını zamanında ve doğru ölçüde yaparsınız.
- Kanıt ve raporlama: Uptime ve performans verisi, hem yönetime hem de KVKK/ISO 27001 kapsamındaki süreklilik tedbirlerine somut kanıt sağlar.
İzleme, felaket kurtarma ve yedeklemenin tamamlayıcısıdır: yedek “olduktan sonra” kurtarır, izleme ise “olmadan önce” uyarır.
Hangi metrikler izlenmeli?
İzleme dört temel katmanda kurgulanır: kaynak (donanım), servis (uygulama), erişilebilirlik (uptime) ve günlükler (log). Aşağıdaki tablo, kurumsal bir sunucuda öncelikli izlenmesi gereken metrikleri ve mantıklı bir başlangıç eşiğini özetler. Eşikler örnektir; gerçek değerler iş yükünüze ve donanımınıza göre ayarlanmalıdır.
| Metrik | Neyi gösterir | Tipik uyarı eşiği |
|---|---|---|
| CPU kullanımı | İşlemci doygunluğu, darboğaz | Sürekli %85 üzeri (5+ dk) |
| Yük ortalaması (load) | Bekleyen iş kuyruğu | Çekirdek sayısının üzerine çıkması |
| Bellek (RAM) kullanımı | Bellek baskısı, swap riski | %90 üzeri veya artan swap |
| Disk doluluğu | Alan tükenmesi | %85 uyarı, %90 kritik |
| Disk I/O / gecikme | Depolama darboğazı | Sürekli yüksek bekleme süresi |
| Ağ trafiği | Bant genişliği, anormal trafik | Beklenmedik ani artış/düşüş |
| Servis durumu | Uygulamanın ayakta olması | Servis durması / yeniden başlaması |
| Uptime / erişim | Dışarıdan erişilebilirlik | Yanıt yok veya yavaş yanıt |
| Sertifika geçerliliği | SSL/TLS süresi | Bitime 30/14/7 gün kala |
| Yedek işi durumu | Yedeğin başarısı | Başarısız veya atlanmış yedek |
Donanım tarafında ek olarak sunucu sıcaklığı, fan durumu, güç kaynağı (PSU) ve RAID dizisi sağlığını da izlemek, fiziksel arızaları öngörmek için değerlidir. Veritabanı çalıştıran sunucularda ise sorgu süreleri, aktif bağlantı sayısı ve kilitlenmeler (lock) gibi uygulama düzeyi metrikler eklenmelidir.
Alarmlar nasıl kurulmalı? (Uyarı yorgunluğundan kaçınmak)
İzlemenin en sık yapılan hatası, her dalgalanma için alarm üretmektir. Sürekli gelen önemsiz uyarılar “uyarı yorgunluğu” (alert fatigue) yaratır ve ekip gerçek alarmı da görmezden gelmeye başlar. İyi bir alarm kurgusunun ilkeleri şunlardır:
- Anlık değil, süreye dayalı eşik: CPU bir saniyeliğine %100’e çıkabilir; bu normaldir. “5 dakika boyunca sürekli %85 üzeri” gibi süre koşulu, geçici dalgalanmaları eler.
- Önem seviyelendirmesi: Uyarıları en az “bilgi”, “uyarı” ve “kritik” olarak ayırın. Disk %85 bir uyarıdır; %95 gece yarısı bile telefon açtıran bir kritik alarmdır.
- Doğru kanal: Kritik alarmlar SMS/telefon/anlık bildirim, düşük öncelikliler e-posta veya panel ile iletilmelidir.
- Yükseltme (escalation): Alarm belirli sürede karşılanmazsa bir üst sorumluya otomatik iletilmelidir.
- Bakım pencereleri: Planlı bakım sırasında alarmları susturarak (mute) gereksiz gürültüyü önleyin.
İyi ayarlanmış bir alarm sistemi az sayıda ama her zaman gerçek ve aksiyon gerektiren uyarı üretir.
Uptime izleme ile kaynak izleme arasındaki fark nedir?
İki yaklaşım birbirini tamamlar ama farklı sorulara cevap verir:
- Uptime (dışarıdan/kara kutu) izleme: Sistemin kullanıcının gördüğü yerden erişilebilir olup olmadığını ölçer. Örneğin web sitenize veya e-fatura servisinize harici bir noktadan düzenli istek atıp yanıt süresini ve durum kodunu kontrol eder. Kullanıcı deneyimini en doğru yansıtan ölçümdür.
- Kaynak (içeriden/beyaz kutu) izleme: Sunucunun içindeki CPU, RAM, disk ve servis durumunu ölçer. Sorunun nedenini anlamak için gereklidir.
İdeal kurulum ikisini birlikte kullanır: uptime izleme “bir sorun var mı?” sorusuna, kaynak izleme ise “sorun neden çıktı?” sorusuna anında cevap verir. “%99,9 uptime” gibi hedefler yılda yaklaşık 8,7 saatlik kesinti bütçesine denk gelir; hedefinizi iş kritikliğine göre belirleyip izlemeyle takip etmek, sözleşmesel taahhütleri ve iç hedefleri ölçülebilir kılar.
Proaktif müdahale: izlemeyi aksiyona çevirmek
Veri toplamak tek başına değer üretmez; önemli olan o veriye bağlı bir müdahale akışı kurmaktır. Proaktif BT yönetimi şu döngüyle çalışır:
- Tespit: Metrik eşiği aşar, alarm tetiklenir.
- Sınıflandırma: Alarmın önem seviyesi ve etki alanı belirlenir.
- Müdahale: Önceden yazılmış bir runbook (eylem rehberi) izlenir; örneğin “disk %90’ı geçerse şu logları temizle, şu sorumluya haber ver”.
- Otomasyon (uygunsa): Tekrarlayan basit aksiyonlar otomatikleştirilebilir; örneğin geçici dosyaların temizlenmesi veya takılan bir servisin kontrollü yeniden başlatılması.
- Kök neden ve önleme: Olay kapandıktan sonra tekrarı önleyecek kalıcı iyileştirme yapılır ve eşikler gözden geçirilir.
Bu döngünün kalbinde runbook vardır: her sık görülen alarm türü için “kim, neyi, hangi sırayla yapacak” sorusunun yazılı cevabı. Kriz anında doğaçlama en pahalı yaklaşımdır.
Sunucu izleme kontrol listesi
Aşağıdaki maddeleri tamamladıysanız sağlam bir izleme pozisyonundasınız:
- Kritik sunucular ve servisler envantere alındı
- CPU, RAM, disk, ağ ve servis durumu metrikleri toplanıyor
- Disk doluluğu için %85 uyarı / %90 kritik eşik tanımlı
- Süreye dayalı eşikler ile geçici dalgalanmalar eleniyor
- Alarmlar önem seviyesine göre (bilgi/uyarı/kritik) ayrıldı
- Kritik alarmlar için anlık bildirim ve yükseltme (escalation) kurulu
- Harici uptime izleme aktif (web/e-fatura/ERP erişimi)
- SSL sertifikası ve yedek işi başarısı izleniyor
- Sık görülen alarmlar için runbook hazır
- Metrikler en az 30-90 gün saklanıyor (eğilim/kapasite analizi için)
- Eşikler düzenli olarak gözden geçirilip ayarlanıyor
KVKK kapsamında kişisel veri işleyen kurumlardan, sistemlerin sürekliliğini ve güvenliğini sağlamaya yönelik teknik tedbirler alması beklenir; izleme ve günlük (log) kayıtlarına ilişkin sektörel yükümlülükler için her zaman güncel resmi kaynağı (KVKK ve ilgili düzenleyici kurum mevzuatı) kontrol edin.
Sıkça Sorulan Sorular
Küçük bir işletmenin tek sunucusu var, izleme yine de gerekli mi? Evet, hatta daha da kritiktir. Tek sunucusu olan bir işletmede o sunucu çökerse yedek bir sistem yoktur; bu nedenle sorunu erken yakalamak çok daha değerlidir. Tek sunuculu kurulumlarda disk doluluğu, yedek başarısı ve servis durumu izlemesi olmazsa olmazdır.
İzleme sistemi sunucuyu yavaşlatır mı? İyi yapılandırılmış bir izleme ajanının (agent) kaynak tüketimi ihmal edilebilir düzeydedir; tipik olarak CPU ve belleğin çok küçük bir kısmını kullanır. Yavaşlamaya neden olan, izlemenin kendisi değil, aşırı sık ölçüm veya kötü yapılandırmadır. Doğru ölçüm sıklığıyla bu sorun yaşanmaz.
Uptime izleme ile sunucu izleme aynı şey mi? Hayır. Uptime izleme sistemin dışarıdan erişilebilir olup olmadığını (sorun var mı?) ölçer; sunucu izleme ise içerideki CPU, RAM ve disk gibi metrikleri (sorun neden çıktı?) ölçer. İkisi birlikte kullanıldığında hem sorun anında haberdar olur hem de nedenini hızla bulursunuz.
Alarmlar sürekli geliyor, ne yapmalıyım? Bu “uyarı yorgunluğu” belirtisidir ve eşiklerinizin yanlış ayarlandığını gösterir. Anlık değil süreye dayalı eşikler kullanın, önem seviyelendirmesi yapın ve gerçekten aksiyon gerektirmeyen uyarıları kapatın. Az ama anlamlı alarm, çok ama göz ardı edilen alarmdan iyidir.
İzleme verilerini ne kadar süre saklamalıyım? Anlık sorun tespiti için kısa süre yeterli olsa da, eğilim ve kapasite analizi yapabilmek için en az 30-90 günlük veri saklanması önerilir. Yıl bazında büyümeyi görmek isteyen kurumlar daha uzun saklama süreleri tercih edebilir.
Sunucularınızı ve kritik iş uygulamalarınızı 7/24 izleyen, sorun büyümeden müdahale eden proaktif bir BT yönetimi kurmak istiyorsanız, Giza Teknoloji olarak Gaziantep/Şehitkamil’den tüm Türkiye’ye destek veriyoruz. İzleme ve alarm altyapısını Server ve Güvenlik (Fortinet) çözümlerimiz, donanım ve bakım hizmetlerimiz ve proje yönetimi / iş zekası ekosistemimizle uçtan uca kurguluyoruz. Ayrıca Netsis 3 ERP, e-dönüşüm, Xenon saha satış ve özel yazılım (PDKS, Tapu, Desen) çözümlerinizin sürekliliğini de aynı izleme çerçevesinde güvenceye alıyoruz.
İhtiyacınıza özel bir değerlendirme için WhatsApp hattımızdan 0532 599 51 12 ile yazın, 0532 599 51 12 numaralı destek hattımızı arayın veya iletişim sayfamız üzerinden bize ulaşın. Firmamız ve çözümlerimiz hakkında daha fazla bilgi için hakkımızda sayfamızı ziyaret edebilirsiniz.