Dlaczego sztywny próg alertu nie działa w monitoringu błędów
Najprostszy sposób na stworzenie alertu wygląda niewinnie: „powiadom mnie, gdy liczba błędów przekroczy 100 na godzinę”. Problem pojawia się wtedy, gdy aplikacja zaczyna się zmieniać. Rośnie ruch, pojawiają się nowe funkcje, zmienia się liczba użytkowników i nagle ustalona kilka miesięcy wcześniej liczba przestaje mieć jakiekolwiek znaczenie.
Monitoring błędów powinien odpowiadać przede wszystkim na jedno pytanie: czy dzieje się coś nietypowego dla tej konkretnej aplikacji? Sama liczba zdarzeń nie zawsze daje na to dobrą odpowiedź.
Ten sam próg nie pasuje do każdej aplikacji
Wyobraź sobie sklep internetowy, który obsługuje tysiące zamówień dziennie. Nawet przy prawidłowym działaniu pojawiają się pojedyncze błędy wynikające z przerwanych sesji, nieudanych prób płatności, timeoutów zewnętrznych usług czy automatycznego ruchu botów.
Jeżeli taki sklep generuje kilkadziesiąt lub nawet kilkaset błędów w ciągu godziny, nie musi to jeszcze oznaczać awarii. Ustawienie alertu na poziomie 100 błędów może więc powodować ciągłe powiadomienia o sytuacjach, które w rzeczywistości są częścią normalnego ruchu.
W drugą stronę działa to jeszcze gorzej. Panel administracyjny używany przez kilka osób może przez większość dnia nie wygenerować ani jednego błędu. Sztywny próg 100 zdarzeń nie zostanie więc osiągnięty nawet wtedy, gdy aplikacja zacznie zwracać błąd 500 przy każdym żądaniu.
Lepszy jest alert oparty na odchyleniu od normy
W monitoringu warto rozdzielić dwie rzeczy: minimalną liczbę zdarzeń oraz odchylenie od typowego poziomu błędów.
Minimalny próg chroni przed fałszywymi alarmami. Jeżeli spokojna aplikacja zwykle generuje jeden lub dwa błędy dziennie, pojedyncze dodatkowe zdarzenie nie powinno budzić całego zespołu.
Drugi element pozwala natomiast zauważyć gwałtowną zmianę. Jeżeli aplikacja zwykle generuje 20 błędów w podobnym okresie, a nagle pojawia się ich kilkukrotnie więcej, jest to znacznie bardziej wartościowa informacja niż sama liczba bez kontekstu.
Norma musi być niezależna od bieżącej awarii
To ważny szczegół projektowania takiego mechanizmu. Nie można wyznaczać normy wyłącznie na podstawie ostatnich kilku minut czy godzin.
Jeżeli awaria zaczyna się powoli i liczba błędów rośnie przez kilka godzin, bieżące dane zaczną zawyżać punkt odniesienia. System może wtedy uznać, że rosnąca liczba błędów jest nową normą dokładnie w momencie, w którym najbardziej potrzebujesz ostrzeżenia.
Dlatego warto opierać punkt odniesienia na dłuższej historii i zagregowanych statystykach. Dzięki temu pojedynczy incydent nie zmienia od razu obrazu normalnego działania aplikacji.
Dlaczego tłumienie alertów jest równie ważne
Nawet dobry mechanizm wykrywania anomalii może stać się uciążliwy, jeżeli każde kolejne okno pomiarowe generuje nową wiadomość.
Awaria może trwać godzinę, kilka godzin albo całą noc. Jeżeli alert wysyłany jest co kilkanaście minut, po kilkudziesięciu wiadomościach trudno już odróżnić moment rozpoczęcia problemu od kolejnych powtórek.
Dlatego monitoring powinien stosować tłumienie powtarzających się powiadomień. Pierwszy alert informuje o problemie, a kolejne wystąpienia są widoczne w historii monitoringu bez zalewania skrzynki pocztowej.
Dobry alert nie powinien informować o wszystkim
Celem monitoringu nie jest wysłanie jak największej liczby powiadomień. Celem jest przekazanie informacji wtedy, gdy ma ona znaczenie.
Sztywny próg odpowiada na pytanie „czy wydarzyło się więcej niż X błędów?”. Monitoring oparty na anomaliach odpowiada na znacznie ważniejsze pytanie: „czy zachowanie aplikacji wyraźnie odbiega od tego, czego można się po niej spodziewać?”
To właśnie ta różnica decyduje o tym, czy alerty pomagają reagować na problemy, czy po kilku tygodniach stają się kolejnym źródłem powiadomień, które można bez zastanowienia wyciszyć.