Wykrywanie nagłych wzrostów liczby błędów

Liczba błędów sama w sobie nie zawsze mówi, że dzieje się coś złego. Aplikacja obsługująca duży ruch może generować więcej zdarzeń niż mały projekt, a chwilowy wzrost liczby wyjątków nie zawsze oznacza awarię.

Dlatego alerty dotyczące błędów powinny uwzględniać nie tylko samą liczbę zdarzeń, ale również typowy poziom błędów dla danego projektu.

Dlaczego stały próg nie zawsze działa?

Próg typu „100 błędów” może być odpowiedni dla jednego projektu, a całkowicie bezużyteczny dla innego. Dla dużej aplikacji 100 błędów może być normalnym poziomem, podczas gdy dla małego serwisu nawet kilkanaście podobnych zdarzeń może oznaczać poważny problem.

Znacznie bardziej użyteczne jest wykrywanie odchylenia od typowego zachowania aplikacji.

Jak wygląda reakcja na wzrost?

Gdy liczba zdarzeń wyraźnie odbiega od obserwowanego poziomu, system może potraktować to jako sygnał wymagający uwagi. Mechanizm uwzględnia również minimalną liczbę zdarzeń, aby pojedynczy przypadkowy wyjątek nie powodował niepotrzebnego alarmu.

Dlaczego nie dostajesz maila przy każdym błędzie?

Powtarzający się problem może wygenerować setki zdarzeń. Wysyłanie osobnego powiadomienia dla każdego z nich szybko zamieniłoby monitoring w źródło szumu.

Dlatego powiadomienia są ograniczane w czasie. Jedna trwająca awaria nie powinna generować kolejnych identycznych wiadomości co kilka sekund.

Co warto zrobić po otrzymaniu alertu?

Najpierw sprawdź, który błąd odpowiada za wzrost oraz kiedy pojawił się po raz pierwszy. Następnie porównaj ten moment z ostatnimi wdrożeniami i zmianami konfiguracji.

Historia liczby wystąpień pozwala szybko ocenić, czy problem nadal narasta, czy był tylko krótkim skokiem.