Przeglądarka i analizator logów online (nginx, Apache, Laravel)

Jak szybko znaleźć błąd w logu — krok po kroku

Najpierw wczytaj dane: wybierz plik z logiem (obsługa do 200 MB, a przy większych plikach narzędzie bierze ostatnie 200 MB) albo wklej fragment tekstu. Cała praca dzieje się w Twojej przeglądarce.

1. Sprawdź rozpoznany format. Narzędzie samo rozpoznaje nginx/Apache combined, Laravel/Monolog, JSON, syslog oraz logi ogólne z poziomami. Wpisy wielowierszowe, na przykład stack trace, są łączone z wpisem nadrzędnym.
2. Zawęź listę do ERROR. Filtr poziomów to najszybszy sposób, żeby odsiać szum i zobaczyć tylko awarie. Potem wróć do WARN, jeśli potrzebujesz kontekstu.
3. Szukaj konkretnej treści. Wpisz nazwę usługi albo endpointu, a gdy potrzebujesz większej precyzji — wyrażenie regularne w formie /wzorzec/. Trafienia są podświetlane.
4. Zerknij na statystyki. Liczba wpisów per poziom pokazuje skalę problemu, a histogram wpisów na godzinę z ostatnich 48 godzin — moment jego rozpoczęcia. Godziny z błędami są na czerwono.
5. Dopasuj analizę do typu logu. W logach dostępowych patrz na kody odpowiedzi, najczęstsze adresy, najaktywniejsze IP i User-Agent. W logach aplikacji — na najczęstsze komunikaty z liczbami zamienionymi na N.
6. Pracuj na wynikach. Lista pokazuje najnowsze 1500 pasujących wpisów, więc im ciaśniej ustawisz filtry, tym szybciej dojdziesz do właściwej linii.

Obsługiwane formaty logów

Nie musisz wybierać formatu z listy — narzędzie rozpoznaje go po treści. Oto, co obsługuje i co z tego wyciąga.

Poziomy sprowadzane są do pięciu grup: ERROR, WARN, INFO, DEBUG i INNE. W logach dostępowych 5xx liczy się jako ERROR, a 4xx jako WARN, więc filtr działa tak samo niezależnie od tego, czy patrzysz na aplikację, czy na serwer.

Analiza logów nginx i Apache

Logi dostępowe są konkretne, bo każdy wiersz to jedno żądanie. Zacznij od statystyk kodów odpowiedzi: liczba 5xx mówi, ile razy zawiódł serwer, a liczba 4xx — ile żądań odrzucono. W tym narzędziu 5xx to ERROR, a 4xx to WARN, więc widzisz problemy bez tracenia kontekstu.

Potem przyjrzyj się trzem zestawieniom:

• Najczęstsze adresy — pokażą, które endpointy generują najwięcej ruchu i gdzie kumulują się błędy. Szukaj miejsc, w których wysoka liczba żądań spotyka się z kodami 5xx.
• Najaktywniejsze IP — jedno IP z setkami żądań na /admin albo /wp-login.php to sygnał, że ktoś sprawdza, co się da. Powtarzalne 4xx na adresach logowania i plikach konfiguracyjnych obejrzyj wiersz po wierszu.
• User-Agent — nietypowe albo puste wartości często oznaczają ruch automatyczny. Zestaw je z adresami, których dany bot nie powinien odwiedzać.

Na koniec spójrz na histogram wpisów na godzinę z ostatnich 48 godzin. Godziny z błędami są na czerwono, więc skok ruchu widać od razu i łatwo powiązać go z wdrożeniem albo falą żądań z jednego źródła. Gdy chcesz zejść do szczegółów, ustaw filtr poziomu i wyszukiwanie — lista pokaże najnowsze 1500 pasujących wpisów.

Analiza logów aplikacji

W logach aplikacji problemem rzadko jest pojedynczy wpis. Zwykle ten sam błąd powtarza się setki razy, za każdym razem z innymi liczbami. Dlatego narzędzie pokazuje najczęstsze komunikaty z liczbami zamienionymi na N — wiersze typu "Nie znaleziono użytkownika 4821" i "Nie znaleziono użytkownika 9137" trafiają do jednej grupy, a Ty widzisz, co naprawdę dominuje.

Stack trace. Ślad błędu bywa rozbity na wiele linii. Wpisy wielowierszowe są łączone z wpisem nadrzędnym, dzięki czemu komunikat i jego ślad czytasz jako jedną całość, a filtrowanie po poziomie nie gubi kontekstu.

Wyszukiwanie tekstowe i wyrażeniem regularnym. Wpisz fragment komunikatu albo wzorzec w formie /treść/. Pasujące fragmenty są podświetlane. Kilka wzorców, które sprawdzają się w praktyce:

• /Exception|Error/ — szeroki przegląd zdarzeń krytycznych.
• /timeout|refused|reset/ — problemy z połączeniami do bazy i usług zewnętrznych.
• /SQLSTATE/ — błędy zapytań do bazy danych.
• /user_id=\d+/ — wpisy dotyczące jednego użytkownika, gdy znasz jego identyfikator.
• /^\[2024-03-12 10:/ — zawężenie do konkretnej godziny, gdy znasz moment awarii.

Po zawężeniu listy wróć do statystyk poziomów. Jeśli ERROR-ów jest dużo, a WARN-ów jeszcze więcej, prawdopodobnie patrzysz na skutki jednego problemu, który zaczął się wcześniej — histogram na to odpowie.

Bezpieczeństwo: logi zawierają IP i dane użytkowników

Log to dane wrażliwe. W wierszu dostępowym masz adres IP, pełny adres żądania z parametrami i User-Agent. W logach aplikacji trafiają się e-maile, identyfikatory użytkowników, fragmenty danych wejściowych, a przy błędach konfiguracji nawet tokeny i hasła. Wystarczy jeden nieuważnie wysłany plik, żeby te informacje wyciekły.

Dlatego analiza w tym narzędziu działa lokalnie: plik i jego treść nie są wysyłane na serwer webp.pl, wszystko przetwarza Twoja przeglądarka. Nie musisz też czekać na wgranie dużego pliku.

Zanim przekażesz log dalej, na przykład do zespołu albo wykonawcy, zanonimizuj go:

1. Skróć adresy IP — w IPv4 zamień ostatni oktet na 0, w IPv6 obetnij końcówkę.
2. Zamień e-maile i identyfikatory użytkowników na oznaczenia, na przykład user_N.
3. Usuń tokeny, klucze, nagłówki autoryzacyjne i wartości ciasteczek.
4. Wytnij parametry zapytań zawierające dane osobowe i zostaw samą ścieżkę.
5. Przejrzyj stack trace oraz kontekst w logach JSON — tam najczęściej zostają wartości zmiennych.

W pracy z logami produkcyjnymi sprawdza się jedna zasada: analiza w przeglądarce, udostępnianie dopiero po anonimizacji.

Najczęstsze pytania

Analiza w przeglądarce; logi nie są wysyłane ani zapisywane.