Ağ ve Uygulama İzleme (Monitoring) ile Proaktif Bakım

Birçok işletmede BT sorunları aynı şekilde fark edilir: bir çalışan telefonu açar ve internetin gitmediğini, ERP'nin donduğunu ya da dosya sunucusuna erişemediğini söyler. Bu noktada kesinti çoktan yaşanmış, iş durmuş ve müdahale baskı altında başlamıştır. Ağ ve uygulama izleme, bu döngüyü tersine çevirir; sorunların büyük kısmı kullanıcı fark etmeden, belirtiler ortaya çıktığı anda görülür. Bu rehberde neyin izlenmesi gerektiğini, uygulama performans izlemenin rolünü, araç seçimini, doğru alarm kurgusunu ve izlemenin ne zaman dış kaynakla yönetilmesinin mantıklı olduğunu ele alıyoruz.

Ağ İzleme Nedir? Reaktif ve Proaktif Bakım Farkı

Ağ izleme; ağ cihazlarının, sunucuların, internet hatlarının ve uygulamaların durumunu ve performansını sürekli ölçen, belirlenen koşullar oluştuğunda uyarı üreten ve bu verileri raporlayan sistemdir. İzlemenin değeri, yalnızca bir cihazın çalışıp çalışmadığını göstermesinde değil, eğilimleri görünür kılmasındadır.

Reaktif bakımda BT ekibi arıza bildirildikten sonra devreye girer. Proaktif bakımda ise sorun henüz kesintiye dönüşmeden müdahale edilir. Farkı somut örneklerle görmek kolaydır:

• Sunucu diski her hafta biraz daha doluyorsa, izleme sistemi disk dolup veritabanı durmadan önce uyarır.
• Bir switch portunda hata sayaçları artıyorsa, bu çoğu zaman bozulmaya başlayan bir kablonun veya konnektörün habercisidir.
• İnternet hattında gecikme ve paket kaybı belirli saatlerde yükseliyorsa, video görüşme şikâyetleri başlamadan operatörle görüşülebilir.
• Yedekleme işi başarısız olduğunda bunun ertesi sabah değil, aynı gece bilinmesi gerekir.
• SSL sertifikası veya alan adı süresinin dolmak üzere olduğu, web sitesi erişilemez hale gelmeden fark edilir.
• UPS batarya durumu zayıfladığında, ilk elektrik kesintisinde sistemler kapanmadan batarya değiştirilir.

Neler İzlenmeli? Cihazlar, Bant Genişliği, Sunucular, Uygulamalar

İzlemeye başlamadan önce güncel bir envanter ve ağ haritası çıkarmak gerekir. Hangi cihazın nerede durduğu, hangi sistemin hangi iş sürecini desteklediği ve hangi bağlantının tek arıza noktası olduğu bilinmeden kurulan izleme, önemli sistemleri atlayıp önemsizlere odaklanabilir. Her sistem için bir iş kritikliği seviyesi belirlemek, hem izleme sıklığını hem de alarm önceliğini doğrudan belirler.

İzleme kapsamını katman katman düşünmek, kör nokta bırakmamanın en güvenli yoludur.

• İnternet ve WAN hatları: Erişilebilirlik, gecikme, paket kaybı, titreşim (jitter) ve hat doluluğu. Şubeler arası tüneller ve yedek hatların gerçekten devreye girip girmediği de izlenmelidir.
• Güvenlik duvarı: İşlemci ve bellek kullanımı, oturum sayısı, VPN tünellerinin durumu, yüksek erişilebilirlik çiftinin sağlığı, lisans ve abonelik süreleri.
• Switch'ler: Port durumları, hata ve atılan paket sayaçları, üst bağlantıların doluluğu, PoE güç bütçesi ve spanning tree topolojisindeki beklenmedik değişiklikler.
• Kablosuz ağ: Erişim noktalarının çevrimiçi durumu, bağlı istemci sayısı, kanal kullanımı ve parazit.
• Sunucular ve sanallaştırma: İşlemci, bellek, disk alanı ve disk gecikmesi, kritik servislerin çalışması, olay günlüklerindeki hatalar, sanallaştırma sunucularının kaynak durumu.
• Depolama ve yedekleme: Disk ve RAID sağlığı, kapasite eğilimi, yedekleme işlerinin sonucu ve süresi.
• Ortam: Sistem odası sıcaklığı, UPS durumu ve batarya sağlığı.
• Bulut servisleri: Microsoft 365 gibi servislerin durumu ve kullanıcıların bu servislere erişim kalitesi.

Bant genişliği tarafında yalnızca hattın ne kadar dolu olduğunu değil, onu kimin ve hangi uygulamanın doldurduğunu bilmek gerekir. Akış verisi, mesai saatinde başlayan bir yedekleme işini veya büyük bir güncelleme indirmesini dakikalar içinde ortaya çıkarır.

Uygulama Performans İzleme (APM) ve Kullanıcı Deneyimi

Ağ izleme ağın ve sunucuların sağlıklı olduğunu söylerken kullanıcılar hâlâ uygulamanın yavaş olduğundan şikâyet edebilir. Uygulama performans izleme (APM) bu boşluğu kapatır ve kullanıcının gerçekte yaşadığı deneyimi ölçer.

APM tarafında izlenmesi gereken temel sinyaller şunlardır:

• Gecikme: İşlemlerin ve sayfaların ne kadar sürede yanıt verdiği
• Trafik: Uygulamaya gelen istek ve işlem hacmi
• Hatalar: Başarısız isteklerin ve uygulama hatalarının oranı
• Doygunluk: Uygulamanın dayandığı kaynakların sınırlarına ne kadar yaklaştığı

Bu sinyallere ek olarak işlem izleme, bir isteğin uygulama sunucusu, veritabanı ve dış servisler arasında nerede zaman kaybettiğini gösterir. Sentetik izleme, oturum açma veya sipariş oluşturma gibi kritik akışları belirli aralıklarla otomatik olarak dener ve kimse kullanmıyorken bile sorunu yakalar. Gerçek kullanıcı izleme ise web ve mobil uygulamalarda kullanıcıların farklı konum ve cihazlardan yaşadığı performansı ölçer.

APM'in pratik faydası, ERP yavaş şikâyeti geldiğinde sorunun ağda mı, sunucuda mı, veritabanında mı yoksa uygulamanın kendisinde mi olduğunu tahminle değil veriyle ayırt edebilmektir. Örneğin sipariş ekranının öğleden sonraları yavaşladığı bir şikâyette ağ grafikleri tamamen normal görünebilir; işlem izleri ise yavaşlığın aynı saatlerde çalıştırılan ağır bir raporun veritabanında kilitlenmeye yol açmasından kaynaklandığını gösterebilir. Bu ayrım, yanlış yere yapılacak donanım yatırımını önler. OpenTelemetry gibi açık standartlar, uygulamalardan veri toplamayı belirli bir üreticiye bağımlı olmadan mümkün kılar.

Araç Seçimi: SNMP, NetFlow ve Popüler İzleme Platformları

İzleme platformları verilerini birkaç temel yöntemle toplar:

• SNMP: Switch, güvenlik duvarı, yazıcı ve UPS gibi cihazlardan durum ve performans verisi okumanın standart yoludur. Güvenlik açısından kimlik doğrulama ve şifreleme sunan SNMPv3 tercih edilmelidir.
• NetFlow, sFlow ve IPFIX: Trafik akışlarının kaynak, hedef, port ve uygulama bazında dökümünü verir; bant genişliğini kimin kullandığını gösterir.
• Syslog ve olay günlükleri: Cihaz ve sunucu olaylarının merkezi olarak toplanmasını sağlar.
• Ajan ve API tabanlı izleme: Sunucu işletim sistemleri, sanallaştırma platformları ve bulut servisleri için daha ayrıntılı veri sunar.

Piyasada sık kullanılan platformlardan PRTG sensör tabanlı yapısı ve hızlı kurulumuyla küçük ve orta ölçekli ağlarda tercih edilir. Zabbix açık kaynaklıdır ve çok esnektir, ancak kurulum ve bakım yetkinliği gerektirir. LibreNMS ağ cihazı ağırlıklı ortamlarda, Prometheus ve Grafana ikilisi ise özellikle modern uygulama ve konteyner ortamlarında öne çıkar. Uygulama performans izleme için ise ticari APM platformları ve açık kaynak alternatifler bulunur.

Seçim yaparken şu kriterleri değerlendirin:

1. İzlenecek cihaz ve sistemlerin çeşitliliği ile ölçek
2. Ekibin yetkinliği ve aracın bakım yükü
3. Lisans modeli: cihaz, sensör veya sunucu bazlı ücretlendirme
4. Yerinde kurulum mu, bulut tabanlı hizmet mi
5. Bildirim kanalları ve yardım masası sistemiyle entegrasyon
6. Raporlama esnekliği ve geçmiş verinin ne kadar süre saklanabildiği

Doğru Eşikler, Alarm Yönetimi ve Raporlama

İzleme sisteminin değeri, ürettiği alarmların kalitesiyle ölçülür. İyi bir alarm kurgusu şu ilkelere dayanır:

1. Önce normali öğrenin: Eşik belirlemeden önce birkaç hafta boyunca sistemlerin olağan davranışını gözlemleyin. Muhasebe sunucusu için normal olan yük, dosya sunucusu için alarm sebebi olabilir.
2. Önem derecesi tanımlayın: Bilgi, uyarı ve kritik seviyelerini ayırın. Kritik alarm, birinin hemen harekete geçmesi gereken durumlar için saklanmalıdır.
3. Süre koşulu ekleyin: Anlık bir işlemci sıçraması alarm üretmemeli; eşiğin belirli bir süre boyunca aşılması beklenmelidir.
4. Bağımlılıkları tanımlayın: Şube güvenlik duvarı erişilemez olduğunda arkasındaki tüm cihazlar için ayrı alarm üretilmemeli, kök neden tek alarmla bildirilmelidir.
5. Bakım pencerelerini işleyin: Planlı çalışmalar sırasında alarmlar bastırılmalıdır.
6. Eskalasyon kurun: Belirli süre içinde ele alınmayan kritik alarm bir üst seviyeye iletilmelidir.
7. Her alarma talimat bağlayın: Alarmı alan kişinin ilk olarak neyi kontrol edeceği kısa bir çalışma talimatıyla tanımlanmalıdır.

Raporlama tarafında aylık erişilebilirlik raporları, kapasite eğilimleri ve en sık alarm üreten sistemlerin listesi, yatırım kararlarının veriye dayanmasını sağlar. Hangi sunucunun ne zaman büyütülmesi, hangi hattın yükseltilmesi veya hangi cihazın ömrünü doldurduğu bu raporlardan okunur.

İzlemeden Yönetime: Otomasyon, Yapılandırma Yedekleri ve Arıza Çözümü

İzleme sorunu gösterir; ağ yönetimi ise çözümün hızlı olmasını ve sorunun tekrarlanmamasını sağlar. Bu iki işi birlikte ele almak, proaktif bakımın ikinci ayağıdır.

• Yapılandırma yedekleri ve değişiklik takibi: Switch, güvenlik duvarı ve erişim noktası yapılandırmaları otomatik olarak düzenli yedeklenmeli, her değişiklik bir önceki sürümle karşılaştırılabilmelidir. Bir cihaz arızalandığında hazır yedek, yeni cihazın devreye alınmasını belirgin şekilde hızlandırır; plansız bir değişiklik ise kimin neyi ne zaman değiştirdiğiyle birlikte görünür hale gelir.
• Rutin işlerin otomasyonu: Durmuş bir servisin yeniden başlatılması, geçici dosyaların temizlenmesi veya ağa eklenen yeni bir cihazın otomatik keşifle izlemeye alınması gibi tekrarlayan işler betiklere ve iş akışlarına bırakılabilir. Otomasyon hem iş yükünü hem de insan hatasını azaltır; ancak her otomatik müdahalenin kaydı tutulmalıdır.
• Yazılım güncellemeleri: Ağ cihazlarının yazılım sürümleri envanterle birlikte takip edilmeli, güvenlik güncellemeleri bakım pencerelerinde planlı olarak uygulanmalıdır.
• Anomali tespiti: Makine öğrenimi destekli platformlar, sistemin olağan davranışından sapmaları izleyerek sabit eşiklerin yakalayamadığı sorunları fark edebilir. Bu özellik iyi kurgulanmış eşiklerin yerini almaz, onları tamamlar.

Arıza anında ise izleme verisi sorun gidermenin yol haritasıdır. Fiziksel bağlantıdan başlayıp ağ, sunucu ve uygulama katmanlarına doğru ilerleyen sistematik bir yaklaşım, grafikler ve olay kayıtlarıyla desteklendiğinde sorunun kaynağını tahminle değil veriyle daraltır. Akış verisinde mesai dışında beklenmedik bir veri çıkışı ya da güvenlik duvarı kayıtlarında reddedilen bağlantılarda ani bir artış gibi sinyaller ise yalnızca performans değil, güvenlik açısından da incelenmelidir.

Sık Yapılan Hatalar: Alarm Yorgunluğu ve Kör Noktalar

İzleme projelerinin başarısız olmasının en yaygın nedeni teknik değil, operasyoneldir. En sık gördüğümüz hatalar şunlardır:

• Alarm yorgunluğu: Her gün yüzlerce önemsiz uyarı üreten sistem kısa sürede görmezden gelinir ve gerçek kritik alarm gürültüde kaybolur.
• Varsayılan eşiklerle çalışmak: Üreticinin varsayılan değerleri sizin ortamınızı tanımaz.
• Herkese her alarmı göndermek: Sorumluluğu belirsiz alarmları kimse sahiplenmez.
• Yalnızca ping ile izlemek: Cihazın yanıt vermesi, sağlıklı çalıştığı anlamına gelmez; servis ve performans da ölçülmelidir.
• Yeni sistemleri izlemeye eklemeyi unutmak: Devreye alma kontrol listesinde izleme adımı yoksa envanter zamanla gerçeklikten kopar.
• Kör noktalar: Şube hatları, yedekleme işleri, sertifika süreleri ve bulut servisleri çoğu zaman kapsam dışında kalır.
• İzleme sisteminin kendisini izlememek: İzleme sunucusu durduğunda sessizlik, her şeyin yolunda olduğu yanılgısını yaratır; dışarıdan basit bir kontrol mutlaka kurulmalıdır.
• Zayıf güvenlik: Varsayılan SNMP topluluk adlarıyla çalışan cihazlar ve geniş yetkili izleme hesapları saldırganlara bilgi sunar.

Performans izleme ile güvenlik izleme birbirini tamamlar ama aynı şey değildir. Tehdit tespiti ve olay müdahalesi tarafını EDR ve SOC ile 7/24 tehdit tespiti yazımızda ele aldık.

İzlemeyi Dış Kaynakla Yönetmek: Ne Zaman Mantıklı?

İzleme aracını kurmak işin kolay kısmıdır; asıl emek alarmları gece gündüz takip etmek, eşikleri ayarlamak ve raporları yorumlamaktır. Aşağıdaki durumlarda izlemenin dış kaynakla yönetilmesi genellikle daha mantıklıdır:

• BT ekibi bir veya iki kişiden oluşuyor ve mesai dışında alarmları takip edecek kimse yoksa
• Birden fazla şube, depo veya üretim tesisi uzaktan yönetiliyorsa
• Kesintinin doğrudan satış, üretim veya hasta hizmeti kaybına dönüştüğü kritik sistemler varsa
• Kurum içinde izleme platformunun kurulum ve bakım yetkinliği bulunmuyorsa

Dış kaynak modelinde sorulması gerekenler şunlardır: Hangi sistemler kapsamda, alarmlar hangi saatlerde ve ne kadar sürede ele alınıyor, yalnızca bildirim mi yapılıyor yoksa müdahale de ediliyor mu, raporlar ne sıklıkla paylaşılıyor ve izleme verisi ile erişim yetkileri nasıl korunuyor? İzleme; yama yönetimi, yedekleme kontrolü ve yardım masasıyla birleştiğinde gerçek proaktif bakıma dönüşür. Bu modelin kapsamını yönetilen IT hizmetleri rehberimizde ayrıntılı olarak anlattık; bilgisayar bakım anlaşması hizmetimiz de bu yaklaşım üzerine kuruludur.

Ağ izleme ve bakımını uzman bir ekibe devretmeyi düşünüyorsanız izlemeyi yeni bir destek firmasına devrederken ilk 30 gün rehberimiz adımları sırasıyla anlatıyor.

Sonuç

Ağ ve uygulama izleme, BT'yi yangın söndürmekten planlı bakıma taşıyan temel yatırımdır. Doğru kapsam, ortamınıza göre ayarlanmış eşikler, sahibi belli alarmlar ve düzenli raporlama ile kesintilerin büyük kısmı kullanıcı fark etmeden önlenebilir. İzleme altyapınızı kurmak, mevcut sisteminizi gözden geçirmek veya izlemeyi network altyapı hizmetimiz kapsamında bize devretmek için ücretsiz ön görüşme planlayabilirsiniz.