Ile danych o błędach naprawdę potrzebujesz w monitoringu aplikacji?

W monitoringu łatwo wpaść w pułapkę myślenia, że więcej danych zawsze oznacza lepszy monitoring. Każdy stack trace, każde żądanie i każda transakcja mogą wydawać się warte zachowania na zawsze.

W praktyce długoterminowe przechowywanie wszystkich surowych zdarzeń ma swoją cenę. Rośnie ilość danych, rosną koszty przechowywania, a analiza historycznych informacji staje się coraz trudniejsza.

Dlatego dobrze zaprojektowany monitoring powinien rozdzielać dane potrzebne do rozwiązania konkretnego problemu od danych, które mają pokazywać długoterminowy trend.

Do czego służą surowe zdarzenia?

Surowe zdarzenie jest najbardziej wartościowe wtedy, gdy próbujesz odpowiedzieć na pytanie: „co dokładnie wydarzyło się w aplikacji?”

Stack trace, komunikat wyjątku, adres żądania, środowisko czy dodatkowy kontekst pozwalają znaleźć przyczynę problemu i odtworzyć sytuację. To dane potrzebne przede wszystkim podczas analizy konkretnego błędu.

Zwykle nie potrzebujesz jednak pełnego stack trace sprzed dwóch lat, aby odpowiedzieć na pytanie, czy aplikacja działała stabilniej w tym miesiącu niż sześć miesięcy wcześniej.

Surowe dane i statystyki to dwie różne potrzeby

Warto więc rozdzielić retencję danych szczegółowych od historii statystyk.

Surowe zdarzenia mogą być przechowywane przez ograniczony czas. W tym okresie masz dostęp do szczegółów potrzebnych do debugowania: komunikatu błędu, stack trace i kontekstu żądania.

Jednocześnie podstawowe informacje mogą być agregowane w dłuższych okresach. Zamiast przechowywać milion pojedynczych zdarzeń, wystarczy zachować informację, że danego dnia wystąpiło 12 438 błędów.

Co warto zachować w historii?

Długoterminowa historia nie musi być skomplikowana. W zależności od rodzaju monitoringu mogą wystarczyć takie informacje jak:

• liczba błędów w danym dniu,
• liczba obsłużonych żądań,
• liczba wystąpień konkretnego problemu,
• średni lub reprezentatywny czas odpowiedzi,
• wyniki pomiarów dostępności i wydajności,
• moment rozpoczęcia i zakończenia problemu.

Tego rodzaju dane zajmują znacznie mniej miejsca niż pełne zdarzenia, a jednocześnie wystarczają do budowania wykresów i analizowania trendów.

Dlaczego agregaty są ważne dla monitoringu błędów?

Agregacja nie służy wyłącznie oszczędzaniu miejsca. Jest również przydatna przy wykrywaniu anomalii.

Jeżeli chcesz stwierdzić, czy dzisiejsza liczba błędów jest nietypowa, potrzebujesz historii, z którą możesz ją porównać. Nie musisz jednak przechowywać wszystkich szczegółowych zdarzeń z każdego poprzedniego dnia.

Dzienna liczba błędów może być wykorzystana jako punkt odniesienia dla kolejnych alertów, nawet wtedy, gdy szczegółowe zdarzenia z tamtego okresu zostały już usunięte.

Retencja danych a limity

Jest jeszcze jeden istotny aspekt: limit liczby zdarzeń nie powinien zależeć od retencji surowych danych.

Jeżeli szczegółowe zdarzenia są regularnie usuwane, ich liczba w bazie nie mówi już, ile zdarzeń zostało odebranych w danym okresie rozliczeniowym. Dlatego zużycie limitu powinno mieć niezależny licznik, który nie znika razem z retencją danych.

Dzięki temu usunięcie starych błędów nie „cofa” wykorzystania limitu i nie zmienia historii zużycia.

Jak znaleźć rozsądny balans?

Dobre podejście polega na zadaniu sobie prostego pytania: czy ta informacja będzie potrzebna do rozwiązania konkretnego problemu, czy tylko do analizy trendu?

Jeżeli potrzebujesz debugowania, zachowaj szczegółowe zdarzenie przez odpowiednio długi czas. Jeżeli interesuje Cię historia działania aplikacji, wystarczy przechowywać zagregowane statystyki.

Takie rozdzielenie pozwala ograniczyć ilość przechowywanych danych bez utraty informacji, które rzeczywiście mają znaczenie dla utrzymania aplikacji.

Monitoring nie musi przechowywać wszystkiego

Najlepszy system monitoringu nie jest tym, który pamięta każdy szczegół bez końca. Jest nim taki system, który przechowuje właściwe dane przez właściwy czas.

Szczegóły pomagają naprawić konkretny błąd. Agregaty pozwalają zrozumieć historię aplikacji. Rozdzielenie tych dwóch warstw daje jednocześnie użyteczny monitoring, sensowną retencję i dostęp do długoterminowych statystyk.