Monitoring ma dawać czas na reakcję, zanim użytkownicy zauważą problem. Źle ustawiony, generuje szum, który uczy zespół ignorowania powiadomień.
Co warto obserwować
- dostępność usług z perspektywy użytkownika, nie tylko serwera,
- miejsce na dyskach z ostrzeżeniem z wyprzedzeniem,
- obciążenie i czas odpowiedzi baz danych,
- wykonanie zadań cyklicznych,
- ważność certyfikatów,
- stan kopii zapasowych.
Lista jest krótka celowo. Monitoring rozpoczęty od zbierania wszystkiego, co narzędzie potrafi zmierzyć, kończy się setkami wykresów, na które nikt nie patrzy. Lepiej zacząć od kilku rzeczy, których awaria zatrzymuje pracę, i dokładać kolejne po każdym incydencie, który nie został wcześniej wykryty.
Sprawdzać skutek, nie objaw
Serwer może odpowiadać, a strona i tak nie działać. Kontrola oparta na rzeczywistym otwarciu strony i sprawdzeniu treści mówi więcej niż odpowiedź na zapytanie sieciowe.
Ta sama zasada dotyczy systemów wewnętrznych. Zamiast pytać, czy usługa jest uruchomiona, warto wykonać operację, którą robi użytkownik: zalogować się, pobrać jeden rekord, wystawić dokument testowy. Sprawdzenie z zewnątrz sieci firmowej dokłada informację, czy problem dotyczy usługi, czy łącza.
Progi
Alert przy dziewięćdziesięciu procentach zajętości dysku bywa spóźniony, jeśli przyrost jest szybki. Lepszy jest próg oparty na prognozie: ostrzeżenie, gdy przy obecnym tempie miejsce skończy się w ciągu tygodnia.
Podobnie z czasem odpowiedzi. Stała wartość graniczna jest myląca, bo system pod koniec miesiąca pracuje inaczej niż w środku. Sensowniejsze jest porównanie do typowego zachowania z tej samej pory dnia i tygodnia. Wymaga to okresu obserwacji przed włączeniem alertów — kilka tygodni bez powiadomień, wyłącznie na zbieranie danych.
Cisza nocna
Nie każdy alert wymaga wybudzenia. Podział na wymagające natychmiastowej reakcji i te do przejrzenia rano jest warunkiem, by ktokolwiek traktował powiadomienia poważnie.
Przy podziale pomaga jedno pytanie: czy o trzeciej w nocy ktoś jest w stanie coś z tym zrobić? Jeśli nie, alert może poczekać do rana. Dochodzi do tego okno serwisowe — powiadomienia z zaplanowanego restartu albo wdrożenia aktualizacji powinny być wyciszone na czas prac, inaczej zespół przyzwyczai się je ignorować.
Alert bez działania
Jeśli na dane powiadomienie nikt nigdy nie reaguje, powinno zostać usunięte albo zmienione. Powiadomienia ignorowane systematycznie psują skuteczność wszystkich pozostałych.
Warto raz na jakiś czas przejrzeć historię alertów i sprawdzić, które z nich w ogóle wywołały czynność. Reszta jest do przerobienia albo do wyłączenia. Alert, który przychodzi codziennie, przestał być alertem i stał się elementem tła.
Co powinno trafiać do monitoringu z innych obszarów
Poza infrastrukturą warto objąć nim rzeczy, które psują się cicho: potwierdzenia wykonania kopii zapasowych, terminy ważności certyfikatów i domen, wygasające klucze do usług zewnętrznych. Każda z tych rzeczy działa bez zarzutu aż do dnia, w którym przestaje — i wtedy jest już za późno na reakcję.
Kiedy prostsze rozwiązanie wystarczy
Przy jednym serwerze i kilku usługach rozbudowana platforma monitorująca bywa nadmiarowa: sama wymaga utrzymania, aktualizacji i pilnowania. Zewnętrzna usługa sprawdzająca dostępność stron plus kilka własnych kontroli zgłaszających się do systemu zgłoszeń daje ten sam efekt mniejszym kosztem.
