Monitoring mówi Ci, że coś nie działa. Trzy główne filary obserwowalności to: metryki – statystyki i pomiary ilościowe (np. czas odpowiedzi, liczba błędów), logi – szczegółowe zapisy zdarzeń w aplikacji, a także trace’y (rozproszone śledzenie) – informacje o przebiegu konkretnego żądania przez cały system. Łącząc te dane, można dokładnie wskazać, gdzie i dlaczego pojawia się problem.
Micrometer – metryki na sterydach
Micrometer to biblioteka w ekosystemie Spring Boot (ale nie tylko), która dostarcza uniwersalny interfejs do zbierania metryk, niezależnie od systemu monitorującego (Prometheus, Datadog, New Relic itd.). Micrometer rejestruje czas odpowiedzi metod, endpointów i baz danych. Monitoruje liczbę błędów (np. wyjątki HTTP 5xx). Pokazuje ilość uruchomień, średni czas wykonania i odchylenia standardowe. Przykładowo, jeśli Twoje API zwalnia, możesz sprawdzić metryki http.server.requests i od razu zobaczyć, które endpointy działają wolno – oraz od kiedy.
Logi – kontekst to klucz
Logi są nieocenione, jeśli metryki pokazują, że „coś jest nie tak”. Dzięki nim można: zidentyfikować konkretne wyjątki, prześledzić sekwencję zdarzeń przed błędem oraz odczytać dane wejściowe prowadzące do problemu.
Dobre praktyki: Używaj strukturalnych logów (np. JSON), aby ułatwić przeszukiwanie i analizę. Dodawaj do logów traceId/requestId (np. z MDC), by powiązać je z trace’ami. Wyróżniaj poziomy logów – nie wszystko musi być błędem.
Tracing – jak śledzić żądanie przez cały system
Gdy masz wiele mikrousług, trace’y pokazują pełną ścieżkę żądania przez system – od gatewaya, przez backend, aż po bazę danych. Popularne narzędzia w tym zakresie to np. OpenTelemetry, Jaeger czy Zipkin. Dzięki tracingowi widzisz, która część łańcucha odpowiadała najdłużej. Możesz zidentyfikować wąskie gardła. W połączeniu z Micrometer i logami pozwala to określić, gdzie dokładnie dzieje się coś złego – i dlaczego.
Przykład z życia – jak połączyć wszystko razem
Załóżmy, że użytkownicy zgłaszają wolne działanie systemu.
Krok 1: Sprawdź metryki (Micrometer) Z http.server.requests wynika, że jeden z endpointów /generateReport trwa średnio 6 sekund, zamiast 1.
Krok 2: Zajrzyj w trace’y OpenTelemetry pokazuje, że 90% czasu spędzane jest w wywołaniu zewnętrznego serwisu raportowego.
Krok 3: Przeanalizuj logi Logi zawierają ostrzeżenie: Timeout while waiting for response from ReportingService.
Diagnoza: Opóźnienie wynika z zewnętrznego serwisu. Dzięki traceId możesz prześledzić wpływ tego opóźnienia na inne komponenty. Wiesz, gdzie wprowadzić retry, timeout lub alternatywne ścieżki.