İki cümle, iki farklı ekipten geliyor. “Bu kayıtlar yeri boşuna dolduruyor.” Ve üç ay sonra: “Mart ayındaki o aktarımın kaydını bulabilir miyiz?” İkisi de haklı ve ikisi aynı ayarı zıt yöne çekiyor.
Karar genellikle kimse fark etmeden veriliyor: temizleme penceresi bir kez ayarlanıyor, sonra dönüp bakan olmuyor. Oysa bu ayar, bir sorunun ardından geriye dönebilme kapasitenizin sınırını çiziyor.
Özet sayaç ile işlem kaydının farkı
Seçimi kolaylaştıran ilk adım, kayıt türlerini ayırmak. Gösterge panelinde servis bazında toplam, başarılı, hatalı ve devam eden işlem sayıları ile son dönem istatistikleri durur. Bu katman tek bir soruyu kapatır: bugün normalden farklı bir şey var mı?
Servis katmanı işin teknik gerçeğini taşıyor. MAIL, WS, WSC, SQL, FILE, CTM, TSAP ve BI servisleri ortak sistem raporunda izlenir; SQL görevleri, SAP görevleri, gelen ve giden servisler, iView çalıştırmaları, dosya işlemleri ve e-posta gönderimleri için ayrı izleme ekranları var.
Saklanan ölçümler tartışmayı bitiren türden: işlem süresi, veri boyutu, paket sayısı, satır ve sütun sayısı, hata metni. Bir aktarımın “yavaşladığını” konuşmak yerine geçen ayın paket sayısı ve süresiyle karşılaştırmak dakikalar sürüyor.
Ekranları ilk kez okuyan biri için küçük bir ipucu: servis adları lisans modülü adlarından daha ayrıntılı. Rapor çalıştırmaları REP modülünün altında REPORT olarak, giden ve gelen servisler API modülünün altında WS ve WSC olarak, e-posta ve dosya işlemleri de MF modülünün altında MAIL ve FILE olarak kaydedilir. Bir hatayı ararken doğru ekranı bulmak bu eşlemeyi bilmekle hızlanıyor.
Log saklama penceresini kim seçiyor
Üçüncü katman kayıtların kendisi: uygulama, servis ve istek günlükleri ile tanım değişikliklerini gösteren denetim kayıtları. Belirli tarihten eski istek ve günlük kayıtları kontrollü olarak temizlenebilir — pencereyi seçen taraf sizsiniz.
İki yol var. Kısa pencere depolama ve sorgu maliyetini düşürür, ama üç ay sonra gelen bir denetim sorusunu cevapsız bırakır. Uzun pencere her soruyu cevaplar; karşılığında büyüyen tablolar ve yavaşlayan sorgular getirir.
İşleyen orta yol, pencereyi tek bir sayı olarak düşünmemek. Ayrıntılı istek ve yanıt kayıtları genellikle kısa bir aralık için işe yarar; işlem özetleri ve değişiklik denetim kayıtları daha uzun tutulmaya değer. Süreyi teknik bir tahminle değil kurumun denetim döngüsüyle hizalamak, kararı savunulabilir kılıyor.
Her kayıt türü için tek bir soru yeterli: bunu kim, hangi soruyu cevaplamak için açacak? Cevabı olan tür daha uzun, cevabı olmayan tür daha kısa tutulur.
İzleme ekranı uyarı sistemi değil
Bir konu daha var: en iyi ölçüm bile kimse bakmadığında yalnızca kayıt olarak kalır. Hata durumunda kimin haberdar olacağını olay aksiyonu ya da e-posta bildirimiyle tanımlamak, izlemeyi karar üretecek hâle getiren adım.
Kendi ortamınızda yapabileceğiniz basit bir sınama var: son çeyrekte hata veren bir işlemi seçin ve kaydının hâlâ orada olup olmadığına bakın. Kayıt yoksa saklama kararınızı aslında kimse vermemiş. Bu sınamayı sizin kayıtlarınız üzerinde yapalım, sonrasında saklama penceresini birlikte yazalım.