Sunucu izleme sisteminin değeri, kaç e-posta gönderdiğiyle değil, ekibin doğru soruna zamanında müdahale edebilmesiyle ölçülür. Her yoğunluk anında gelen ve kimin ilgileneceği belli olmayan bildirimler, önemli bir kesintinin diğer mesajlar arasında kaybolmasına yol açabilir. Alarm yorgunluğunu azaltmak için önce hangi olayın gerçekten işlem gerektirdiğini tanımlayın.
İstanbul'da merkez ofisi, farklı lokasyonlarda çalışan kullanıcıları ve merkezi bir ERP sunucusu bulunan bir işletmeyi düşünelim. Sabah giriş yoğunluğu, gün içindeki raporlar ve gece yedeklemesi aynı kaynak kullanımını üretmez. Bu kurgusal senaryo, tek bir eşiği bütün sunuculara uygulamak yerine iş akışına göre uyarı tasarlamanın neden gerekli olduğunu gösterir.
1. İzleme hedefini kullanıcı etkisiyle ilişkilendirin
İlk soru “CPU yüzde kaç olunca haber gelsin?” olmamalıdır. Önce korunacak hizmeti seçin: ERP erişimi, uzak uygulama oturumları veya müşteriye açık bir web sitesi. Ardından bu hizmetin aksaması halinde hangi ekibin, hangi kararı vereceğini yazın. Bir metriğin yükselmesi inceleme işaretidir; tek başına sorunun nedenini kanıtlamaz.
Her uyarı için kısa bir kayıt hazırlayın: izlenen sunucu veya adres, metrik, eşik, iş etkisi, sorumlu kişi ve ilk kontrol adımı. Alıcıların “Bu mesaj bana neden geldi?” sorusunu sormadan harekete geçebilmesi amaçlanmalıdır.
2. Normal çalışma düzenini ölçün
Eşik seçmeden önce farklı iş dönemlerini gözlemleyin. Sabah oturum açılışı, normal çalışma, toplu rapor üretimi ve yedekleme sırasında görülen değerleri ayrı değerlendirin. Ay sonu gibi yoğun bir dönemin sonuçlarını sakin bir günle aynı kabul etmeyin. Gözlem aralığını işletmenin çalışma döngüsünü temsil edecek şekilde belirleyin.
Bu aşamada bir başlangıç tablosu tutun: dönem, aktif kullanıcı sayısı, kaynak kullanımı ve kullanıcıdan gelen performans geri bildirimi. Amaç her dalgalanmayı susturmak değil, beklenen yükü gerçek kapasite sorunu ve erişim kaybından ayırmaktır. Bir sunucuda olağan görünen değer, farklı görevi olan başka bir sunucu için anlamlı olmayabilir.
3. TSplus uyarılarını ihtiyaca göre düzenleyin
TSplus Server Monitoring içinde Alerts bölümünün Management ekranından uyarılar yönetilir. Sunucular için işlemci, bellek, disk okuma/yazma, ağ kullanımı, disk doluluğu, aktif kullanıcı ve erişilememe süresi; web siteleri için yanıt süresi ve erişilememe süresi uyarıları tanımlanabilir. Kurulumda oluşan temel uyarıları da gözden geçirin.
Önce hedef sunucu veya siteyi, ardından ilgili metriği ve kendi ortamınıza uygun parametreleri seçin. Tüm sistemlere aynı değerleri kopyalamadan önce pilot bir hedefte doğrulama yapın. Teknik kaynak: TSplus Alerts Management dokümanı. Bu rehberdeki operasyon önerileri ürünün varsayılan eşikleri veya otomatik iş akışları değildir; kurulu sürümde mevcut seçenekleri doğrulayın.
4. Her uyarıyı somut bir ilk kontrole bağlayın
Aşağıdaki tablo kurumunuz için uyarlanabilecek bir müdahale taslağıdır. Öncelik ve kontrol sırası hizmetin önemine göre değişebilir.
| Uyarı | İlk kontrol | İlgili ekip |
|---|---|---|
| Sunucuya erişilemiyor | İzleme bağlantısını ve hedef sunucunun durumunu ayrı doğrulayın | Altyapı ve ağ |
| Disk doluluğu artıyor | Büyüyen dosya veya veri alanını belirleyin; onaysız silme yapmayın | Sistem ve uygulama |
| İşlemci veya bellek yüksek | İlgili süreçleri, kullanıcı yükünü ve aynı saatteki işleri inceleyin | Sistem ve uygulama |
| Web yanıt süresi yükseldi | Hedef sayfayı ve ölçüm yolunu kontrol edin; uygulama sağlığını ayrıca test edin | Web, uygulama ve ağ |
Kaynak uyarısı geldiğinde sunucuyu hemen yeniden başlatmak yerine belirtileri ve etkilenen kullanıcıları kaydedin. Aynı dakikada gelen birden fazla bildirimi ortak olay zamanı ve hedef üzerinden birlikte değerlendirin. Bu, ekibin olay inceleme yöntemidir; ürünün otomatik kök neden analizi yaptığı anlamına gelmez.
5. Bildirimin doğru kişiye ulaştığını test edin
Bir alarmın ekranda görünmesi, e-postanın sorumlu kişiye ulaştığını göstermez. TSplus, eşik tetiklendiğinde ve metrik normale döndüğünde e-posta bildirimi sunar. Uyarıya birden fazla alıcı eklenebilir; alıcı alanı boş bırakılırsa olay yine alarm geçmişinde görülebilir. Bu ayrımı test kaydınıza ekleyin.
E-posta ayarları için ürünün Settings dokümanındaki SMTP yapılandırmasını ve Test SMTP Settings kontrolünü kullanın. Sonrasında yetkili bir pilot testle gerçek alarmın da teslim edildiğini doğrulayın. Spam veya karantina, alıcı listesi ve kurumun posta politikası gibi noktaları kontrol edin; yalnızca gönderici ekranındaki başarı mesajıyla yetinmeyin.
Birincil ve yedek sorumluyu kurum içinde belirleyin. Her bildirimi bütün ekibe göndermek yerine, konuyla ilgilenen kişilerin takip ettiği adresleri seçin. Nöbet, yönlendirme veya destek kaydı süreci gerekiyorsa bunu kullandığınız operasyon araçlarında ayrıca kurun; ürünün kendiliğinden bu süreçleri oluşturduğunu varsaymayın.
6. Bakım ve iyileşme kontrollerini planlayın
Yedekleme veya planlı bakım sırasında beklenen değişimleri bakım kaydıyla ilişkilendirin. Bildirim yoğunluğunu azaltmak için izlemeyi topluca kapatmak yerine, hangi uyarının neden oluştuğunu inceleyin. Geçici bir kural değişikliği gerekiyorsa önceki ayarı, sorumluyu ve geri dönüş zamanını kaydedin.
Normalleşme bildirimi geldiğinde kullanıcıların işini yeniden yapabildiğini de kontrol edin. CPU değerinin düşmesi ERP işleminin düzeldiğini tek başına kanıtlamaz. Tersine, sunucu erişilebilir olsa bile bir uygulama işlemi başarısız olabilir. Web erişilebilirlik ve kaynak ölçümlerini, uygulamanın gerçek işlev testiyle tamamlayın.
7. Alarm geçmişini düzenli olarak değerlendirin
TSplus alarm geçmişinde hedefi, olayın başlangıcını ve bitişini inceleyebilirsiniz. Bu kaydı destek talepleri ve bakım takvimiyle karşılaştırın. Aynı uyarı tekrar tekrar geliyor ve hiçbir müdahale gerektirmiyorsa eşik, hedef veya iş süreci yeniden değerlendirilmeli; gerçekten gerekli bir uyarı ise temel sorun çözülmelidir.
Haftalık gözden geçirmede şu bilgileri not edin: toplam olay, işlem gerektiren olay, tekrarlayan bildirimler ve sorumlusu belirsiz kalan uyarılar. Yalnızca alarm sayısının azalmasını başarı saymayın. Kontrollerin amacı, önemli bir sorunun gözden kaçmasına yol açmadan daha anlaşılır bir müdahale düzeni oluşturmaktır.
Canlı kullanım öncesi kısa kabul kontrolü
- Doğru sunucu veya web adresinin izlendiği doğrulandı mı?
- Seçilen eşik ve parametreler normal iş yüküyle karşılaştırıldı mı?
- Pilot alarm, geçmişte ve beklenen alıcının posta kutusunda görüldü mü?
- Normalleşme ve kullanıcı tarafındaki hizmet durumu kontrol edildi mi?
- İlk müdahale adımı, sorumlu ve yedek sorumlu belli mi?
- Test için değiştirilen ayarlar uygun değerlere geri alındı mı?
Testleri üretimde kesinti yaratarak yapmak zorunda değilsiniz. Ayrı test hedefi veya onaylanmış, kontrollü bir test yöntemi seçin. Daha geniş değerlendirme için uzak erişim PoC kontrol listesini de planınıza ekleyebilirsiniz.
Sık sorulan sorular
Tek bir CPU eşiği bütün sunucular için yeterli mi?
Sunucu rolleri ve iş yükleri farklıdır. Önce normal çalışma düzenini ölçün, ardından hizmetin ihtiyacına göre eşik belirleyip pilot testle doğrulayın.
Alarm geçmişinde kayıt var ama e-posta gelmiyorsa ne yapılmalı?
Uyarının alıcı alanını, SMTP testini ve posta sistemindeki teslim durumunu birlikte kontrol edin. Geçmiş kaydı ile e-posta teslimi farklı doğrulama adımlarıdır.
Normalleşme mesajı destek kaydını kapatmak için yeterli mi?
Önce etkilenen hizmette örnek bir kullanıcı işlemini doğrulayın. Metrik normalleşmesini, yapılan müdahaleyi ve hizmetin sonucunu destek kaydında birlikte değerlendirin.
İlk adımı üç anlamlı uyarıyla atın
Önce kritik bir sunucu, önemli bir kapasite göstergesi ve kullanıcıya açık bir web hedefi seçin. Her biri için sorumlu, eşik ve ilk kontrolü tanımlayıp bildirim zincirini test edin. Kendi ortamınızda değerlendirme yapmak için TSplus deneme sürümlerini inceleyin veya TSplus Türkiye ekibiyle iletişime geçin.