Zaawansowane filtrowanie i wyszukiwanie w Kibana: sekretne triki dla efektywnej analizy logów w QA

Większość testerów i inżynierów QA traktuje Kibanę jak prostą wyszukiwarkę Google dla logów. Wpisują ID transakcji, może słowo „error” i liczą na to, że odpowiedź pojawi się w pierwszych pięciu wynikach. To podejście działa przy małej skali, ale w złożonych systemach rozproszonych, gdzie logi płyną strumieniami gigabajtów na godzinę, podstawowe wyszukiwanie to strata czasu.

Efektywna analiza logów nie polega na szybkim czytaniu, ale na precyzyjnym odrzucaniu szumu. Kibana oferuje potężne narzędzia, które często pozostają ukryte pod maską interfejsu Discover. Jeśli chcesz szybciej diagnozować błędy regresji i przestać tonąć w danych, musisz przejść na wyższy poziom filtrowania.

Przejdź na KQL i zapomnij o Lucene

Przez lata domyślnym językiem zapytań w Kibanie był Lucene. Jest potężny, ale jego składnia bywa toporna i nieintuicyjna. Jeśli nadal go używasz, czas przełączyć się na Kibana Query Language (KQL). To nie jest tylko kwestia estetyki – to kwestia szybkości pracy.

KQL oferuje genialne podpowiadanie składni (autocomplete). Gdy zaczynasz pisać nazwę pola, Kibana podpowiada dostępne opcje i, co ważniejsze, sugeruje wartości, które faktycznie występują w logach w wybranym zakresie czasu. Dzięki temu nie musisz zgadywać, czy pole nazywa się user_id, userId czy user.id.

Przykład prostego, ale skutecznego zapytania w KQL dla QA:

http.response.status_code >= 400 and not http.response.status_code: 404 and env: "staging"

To zapytanie natychmiast wycina szum związany z błędami „nie znaleziono” (które często są fałszywymi alarmami w środowiskach testowych) i skupia się na rzeczywistych problemach serwera lub walidacji.

Operator exists: szukanie tego, czego nie ma

W testowaniu oprogramowania często ważniejsze od tego, co jest w logach, jest to, czego w nich brakuje. Brakujące pole w obiekcie JSON może świadczyć o błędzie serializacji, problemie z migracją bazy danych lub cichym niepowodzeniu integracji.

Większość inżynierów QA nie wie, jak szukać braku danych. Tutaj wchodzi operator exists. Jeśli chcesz znaleźć logi, w których brakuje kluczowego identyfikatora, użyj:

not _exists_: "order.id"

To zapytanie jest bezcenne podczas testów integracyjnych. Pozwala wyłapać te rzadkie przypadki brzegowe, gdzie system nie rzucił wyjątkiem (więc nie ma słowa „error”), ale proces biznesowy nie został poprawnie zainicjowany.

Filtrowanie zakresów nie tylko dla dat

Filtrowanie po czasie jest oczywiste (korzystasz z pickera w prawym górnym rogu), ale operatorzy zakresu w pasku wyszukiwania to potężne narzędzie do analizy wydajności. Jako QA powinieneś interesować się nie tylko tym, czy funkcja działa, ale czy działa w akceptowalnym czasie.

Zamiast czekać na raporty z narzędzi do testów wydajnościowych, możesz na bieżąco monitorować powolne zapytania w środowisku testowym:

transaction.duration_ms > 2000

Możesz łączyć to z konkretnymi endpointami, aby udowodnić deweloperowi, że jego ostatnia poprawka drastycznie spowolniła wyszukiwanie produktów. To twarde dane, z którymi trudno dyskutować.

Wieloznaczników używaj z głową

Gwiazdka (*) to miecz obosieczny. Używana na początku frazy (np. *Exception) jest zabójcza dla wydajności klastra Elasticsearch, ponieważ zmusza silnik do przeskanowania każdego termu w indeksie. Administratorzy ELK Stacka znienawidzą cię za to.

Zamiast tego używaj wieloznaczników na końcu frazy lub w środku, jeśli to absolutnie konieczne. Jednak o wiele lepszą techniką dla QA jest wykorzystanie operatora in, gdy szukasz kilku konkretnych wartości:

service.name in ("auth-service", "payment-gate", "cart-manager")

Jest to znacznie czytelniejsze i szybsze niż wielokrotne stosowanie or.

Personalizacja widoku discover

Domyślny widok w zakładce Discover pokazuje pole _source, czyli surowy JSON. Czytanie tego przy setkach logów jest męczące i nieefektywne. Jednym z najważniejszych „trików” jest po prostu skonfigurowanie kolumn.

Z lewego panelu bocznego wybierz tylko te pola, które są istotne dla twojego obecnego testu, np. timestamp, log.level, message i correlation_id. Kliknij „toggle column” przy każdym z nich. Tabela stanie się czytelna jak Excel. Widzisz wzorce na pierwszy rzut oka, zamiast parsować wzrokiem klamry JSON-a.

Co więcej, taki widok możesz zapisać (Save Search). Stwórz sobie widoki dla różnych scenariuszy: „Błędy Płatności”, „Logi API Gateway”, „Slow Queries”. Dzięki temu, gdy zgłaszasz błąd, nie musisz od nowa budować kontekstu – wchodzisz w zapisany widok i od razu widzisz anomalię.

Analiza sąsiedztwa logów

Często sam błąd (stack trace) nie mówi wszystkiego. Ważne jest to, co wydarzyło się milisekundy przed nim. Kibana posiada funkcję „View surrounding documents”. Gdy znajdziesz interesujący cię log błędu, kliknij małą ikonę dokumentu po lewej stronie wiersza, a następnie link „View surrounding documents”.

To przeniesie cię do widoku, który pokazuje wpisy z tego samego indeksu, które wystąpiły tuż przed i tuż po wybranym zdarzeniu, niezależnie od tego, czy pasują do twoich obecnych filtrów wyszukiwania. To kluczowe przy debugowaniu problemów ze współbieżnością (race conditions), gdzie przyczyna błędu leży w innym wątku lub serwisie, który logował się ułamek sekundy wcześniej.