Od logu do buga: studium przypadku, jak Kibana uratowała produkcję

Każdy inżynier oprogramowania zna ten scenariusz. Jest piątkowe popołudnie, zespół powoli zamyka zadania, a system monitoringu nagle zaczyna świecić na czerwono. W tym konkretnym przypadku pracowaliśmy nad platformą e-commerce o dużym natężeniu ruchu. Zgłoszenia od użytkowników były niepokojące, ale mało precyzyjne: „nie mogę zapłacić”, „koszyk się zawiesza”, „widzę biały ekran”.

W środowisku rozproszonym, gdzie mikroserwisy komunikują się ze sobą setki razy na sekundę, tradycyjne metody debugowania zawodzą. Logowanie się przez SSH na poszczególne maszyny i używanie grep w poszukiwaniu błędów to szukanie igły w stogu siana, który w dodatku płonie. Tutaj do gry weszła Kibana, stanowiąca część naszego stosu ELK (Elasticsearch, Logstash, Kibana).

Zgłoszenie, które zrujnowało piątek

Pierwszym sygnałem był skokowy wzrost błędów HTTP 500 na bramce API. Wykresy w Grafanie pokazały anomalię, ale nie dawały odpowiedzi na pytanie „dlaczego?”. Wiedzieliśmy tylko, że problem dotyczy serwisu płatności, ale ten serwis zależał od trzech zewnętrznych dostawców i dwóch wewnętrznych baz danych. Bez scentralizowanych logów spędzilibyśmy godziny na analizie każdego komponentu z osobna.

Wizualizacja problemu w Kibanie

Zamiast przeglądać surowe pliki tekstowe, otworzyliśmy nasz główny dashboard w Kibanie. Pierwszym krokiem było zawężenie zakresu czasowego do ostatnich 15 minut, kiedy zaczęły spływać zgłoszenia. Widok „Log Volume” potwierdził nasze obawy – liczba logów o poziomie ERROR wzrosła o 400% w stosunku do normy.

Dzięki odpowiedniemu ustrukturyzowaniu logów w formacie JSON, mogliśmy natychmiast skorzystać z panelu bocznego, aby przefiltrować ruch. Użyliśmy prostego zapytania KQL (Kibana Query Language):

service.name: "payment-service" AND log.level: "ERROR"

To natychmiast odsiało szum generowany przez inne serwisy, które mogły zgłaszać błędy wtórne (np. timeouty wynikające z przeciążenia).

Izolowanie anomalii

Patrząc na przefiltrowane wyniki, zauważyliśmy interesujący wzorzec w polu transaction.type. Błędy nie dotyczyły wszystkich płatności. Transakcje kartowe przechodziły bez problemu, natomiast błędy kumulowały się wyłącznie przy próbach płatności szybkim przelewem (pay-by-link).

Agregacja danych zamiast czytania wierszy

Zamiast czytać każdy log po kolei, stworzyliśmy szybką wizualizację typu „Data Table” w sekcji Visualize, grupując błędy po polu error.message. To kluczowy moment, który odróżnia pracę z Kibaną od pracy z konsolą. W ciągu kilku sekund zobaczyliśmy, że 95% błędów ma ten sam komunikat:

Connection refused: upstream provider API timeout

Od ogółu do szczegółu: namierzanie winowajcy

Wiedzieliśmy już, że winny jest timeout, ale który dostawca? Nasz serwis integrował się z wieloma. Kliknięcie w lupę przy konkretnym komunikacie błędu pozwoliło nam wejść w tryb „Drill down”. Wyświetliliśmy pełny dokument JSON pojedynczego logu.

Dzięki temu, że nasze logi zawierały pole upstream.provider_id, natychmiast zidentyfikowaliśmy, że problem dotyczy konkretnego dostawcy usług bankowych, który właśnie wdrożył aktualizację swojego API. Co ciekawe, aplikacja nie obsługiwała poprawnie braku odpowiedzi w specyficznym scenariuszu brzegowym, co prowadziło do niekontrolowanego wyjątku i zwrócenia użytkownikowi błędu 500 zamiast estetycznego komunikatu „Spróbuj ponownie”.

Weryfikacja poprawki w czasie rzeczywistym

Diagnoza zajęła nam mniej niż 10 minut. Zespół developerski przygotował hotfix, który wprowadzał agresywniejszy timeout dla tego konkretnego dostawcy oraz poprawną obsługę błędu (tzw. graceful degradation). Po wdrożeniu poprawki na produkcję nie musieliśmy czekać na telefony od klientów, by potwierdzić skuteczność działań.

W Kibanie obserwowaliśmy wykres w czasie rzeczywistym. Ustawiliśmy interwał odświeżania na 5 sekund. Zobaczyliśmy, jak słupki reprezentujące logi ERROR gwałtownie spadają, a rośnie liczba logów INFO z nowym komunikatem o obsłużonym błędzie połączenia. Ruch użytkowników wrócił do normy, a my mogliśmy zamknąć incydent jeszcze przed końcem dnia pracy.