AI w analizie logów Linux

Analiza logów to jeden z tych obszarów, w których AI wygląda kusząco. Wystarczy wkleić fragment pliku, zapytać “co tu się stało?” i po chwili dostać sensownie brzmiące podsumowanie.

Problem w tym, że produkcyjne logi rzadko są krótkim fragmentem. Częściej są chaotycznym strumieniem informacji: warningów, błędów, powtarzalnych requestów, timeoutów, prób logowania, zadań cron i komunikatów aplikacji. Jeżeli wyślesz to wszystko do modelu bez przygotowania, dostaniesz kosztowną zgadywankę.

AI może pomóc w analizie logów, ale najlepiej działa jako warstwa interpretacji po wcześniejszym uporządkowaniu danych. W środowiskach, gdzie logi mają wspierać bieżącą reakcję na zdarzenia, dobrym fundamentem jest monitoring Wazuh i analiza alertów, a dopiero nad nim warstwa AI.

Najpierw redukcja szumu

W logach większość wpisów nie opisuje problemu. Są rutynowe, powtarzalne i potrzebne głównie jako tło. Dlatego pierwszy etap powinien być lokalny:

ograniczenie zakresu czasu,
wybranie właściwego źródła logów,
policzenie statusów i typów zdarzeń,
wyłapanie błędów, timeoutów i anomalii,
usunięcie duplikatów lub powtarzalnych linii.

Przykład prostego zawężenia:

journalctl -u ssh --since "24 hours ago"    # Debian, Ubuntu
journalctl -u sshd --since "24 hours ago"   # RHEL, Rocky, AlmaLinux
journalctl -p warning --since "2 hours ago"
grep " 5[0-9][0-9] " /var/log/nginx/access.log | tail -100

Model nie powinien być pierwszym narzędziem, które widzi surowy log. Najpierw warto zebrać sygnał, a do tego dobrze sprawdzają się zwykłe narzędzia terminalowe: lnav do interaktywnego przeglądania i filtrowania logów, goaccess do szybkich statystyk ruchu z logów webowych. Żadne z nich nie rozumie kontekstu tak jak model językowy, ale w kilka sekund pokazują obraz, który inaczej trzeba by budować ręcznie z grep i awk.

Heurystyki nadal mają sens

AI nie zastępuje prostych reguł. Jeżeli w auth.log widać setki nieudanych logowań z jednego adresu IP, nie potrzeba modelu językowego, żeby nazwać to brute force.

Lokalne heurystyki są szybkie, tanie i przewidywalne:

wiele błędów logowania z jednego IP,
nagły wzrost statusów 500,
powtarzalne timeouty upstream,
nietypowe User-Agenty,
skanowanie popularnych ścieżek,
błędy DNS lub TLS,
restarty usługi w krótkim czasie.

AI może później pomóc opisać znaczenie tych sygnałów, ułożyć raport albo wskazać kolejne pytania diagnostyczne, ale nie musi wykrywać wszystkiego od zera.

Gdzie AI naprawdę pomaga

Największa wartość AI w analizie logów pojawia się tam, gdzie trzeba połączyć kilka obserwacji w czytelny opis.

Przykładowo:

streszczenie incydentu dla osoby nietechnicznej,
uporządkowanie timeline’u zdarzeń,
wskazanie prawdopodobnej przyczyny na podstawie kilku źródeł,
zamiana chaotycznych notatek w raport Markdown,
przygotowanie checklisty dalszej diagnostyki,
wyjaśnienie nieznanych komunikatów błędów.

To zadania, w których model językowy jest przydatny, bo dobrze operuje tekstem, kontekstem i strukturą raportu.

Gdzie AI przeszkadza

AI zaczyna przeszkadzać, gdy traktuje się je jak wyrocznię. Model może brzmieć pewnie, nawet kiedy nie ma pełnego kontekstu. Może dopowiedzieć brakujące elementy, pomylić przyczynę ze skutkiem albo uznać normalny wzorzec ruchu za incydent.

Szczególnie warto uważać na:

analizę bardzo krótkich fragmentów bez kontekstu,
logi z systemów, których model nie zna,
automatyczne rekomendacje zmian konfiguracyjnych,
klasyfikowanie incydentu bez potwierdzenia w danych,
wnioski typu “na pewno” tam, gdzie są tylko poszlaki.

W praktyce AI powinno formułować odpowiedzi ostrożnie: “to wygląda jak”, “sprawdź jeszcze”, “możliwa przyczyna”. Ostateczna decyzja nadal należy do człowieka.

Warto pamiętać, że log to niezaufane wejście: znajdują się w nim wartości, które częściowo kontroluje ktoś z zewnątrz, na przykład nagłówek User-Agent, ścieżka requestu czy treść wiadomości e-mail w logu serwera pocztowego. Atakujący, który wie, że logi trafiają do modelu, może spróbować wstrzyknąć w nie tekst wyglądający jak instrukcja. Dopóki AI tylko opisuje log i nie ma dostępu do narzędzi wykonujących akcje, ryzyko jest ograniczone do wprowadzenia analizy w błąd. Staje się poważniejsze w momencie, gdy analiza logów zostanie połączona z agentem, który na podstawie wniosków z logu może coś wykonać.

Jednym ze sposobów ograniczenia zgadywania jest dostarczenie modelowi kontekstu, którego sam nie zna: fragmentów runbooków, opisów podobnych incydentów z przeszłości albo dokumentacji architektury. Model, który dostaje do dyspozycji rzeczywisty zapis “ten sam błąd pojawił się trzy miesiące temu i wynikał z X”, ma zwykle mniej powodów do zgadywania niż model proszony o wniosek wyłącznie na podstawie samego logu. To zasada, na której opiera się RAG (retrieval augmented generation) w większych wdrożeniach. Warto jednak nie mylić tego z gwarancją poprawności: RAG nie eliminuje halucynacji, model nadal może błędnie zinterpretować dostarczony dokument, pominąć istotny fragment albo źle połączyć fakty z różnych źródeł. Ogranicza konieczność zgadywania, ale nie zastępuje weryfikacji wniosku.

Warto też wiedzieć, że nie trzeba budować własnego pipeline’u od zera, choć przy własnych, specyficznych potrzebach to wciąż sensowna opcja — przykład takiego podejścia opisuję przy projekcie AI Log Analysis CLI. Platformy obserwowalności coraz częściej mają wbudowaną warstwę AI: Elastic AI Assistant, Datadog Bits AI czy Splunk AI Assistant robią część tej redukcji szumu i interpretacji automatycznie, w kontekście danych, które już zbierają. Własny pipeline ma sens tam, gdzie potrzebna jest kontrola nad tym, co i gdzie trafia, gotowe narzędzie tam, gdzie ta kontrola jest mniej krytyczna niż czas wdrożenia.

Prywatność logów

Logi często zawierają więcej danych, niż się wydaje. Mogą trafić do nich:

adresy IP użytkowników,
adresy e-mail,
tokeny sesyjne,
fragmenty requestów,
ścieżki plików,
nazwy klientów lub projektów,
payloady błędów aplikacji,
dane osobowe wpisane w formularz.

Tokeny sesyjne, klucze API i inne sekrety, które potrafią trafić do logów, wymagają tego samego traktowania co sekrety w kodzie i konfiguracji — jeśli wyciekną przez log wysłany do zewnętrznego API, konsekwencje są identyczne jak przy wycieku z repozytorium. Dlatego wysyłanie logów do zewnętrznego API wymaga decyzji, nie odruchu. Minimum ostrożności to ograniczenie zakresu czasu, usunięcie danych wrażliwych i wysłanie tylko tego, co rzeczywiście potrzebne do analizy.

Docelowo dobry pipeline powinien mieć maskowanie danych przed etapem AI:

log source -> filtr czasu -> heurystyki lokalne -> maskowanie -> AI summary -> raport

To nie rozwiązuje wszystkich problemów, ale zmniejsza ryzyko przypadkowego wyniesienia danych poza środowisko.

Dla środowisk, w których logi w ogóle nie powinny opuszczać infrastruktury, na przykład ze względu na regulacje albo umowy z klientami, alternatywą jest model uruchomiony lokalnie, na przykład przez Ollamę na tej samej maszynie albo w tej samej sieci. Mniejszy model lokalny nie dorówna jakością największym modelom chmurowym, ale do zadań takich jak streszczanie, klasyfikacja czy pierwsze rozeznanie w logach często wystarcza, a sam prompt nie musi opuszczać infrastruktury. To zależy jednak od konfiguracji całego pipeline’u: telemetrii samego narzędzia, dodatkowych integracji i tego, czy któryś element po drodze i tak nie wysyła czegoś na zewnątrz, więc “lokalnie” warto zweryfikować, a nie zakładać z góry.

Dobry workflow

Sensowny przepływ pracy z AI przy logach może wyglądać tak:

Wybierz źródło logów i zakres czasu.
Lokalnie policz podstawowe metryki i błędy.
Wyodrębnij reprezentatywne linie zamiast całego pliku.
Usuń albo zamaskuj dane wrażliwe.
Poproś model o interpretację, timeline i dalsze kroki.
Zweryfikuj wnioski w systemie.
Zapisz raport razem z komendami, które potwierdzają ustalenia.

Taki proces jest mniej efektowny niż wklejenie wszystkiego do czatu, ale dużo bardziej użyteczny.

Przykład dobrego pytania do modelu

Zamiast pytać:

Co jest nie tak z tym logiem?

lepiej podać kontekst:

Analizuję log nginx z ostatnich 30 minut po zgłoszeniu problemów z logowaniem. Poniżej masz zagregowane statusy HTTP, przykładowe błędy 5xx i fragment error.log. Wskaż najbardziej prawdopodobne hipotezy, czego brakuje do potwierdzenia i jakie komendy warto uruchomić dalej. Nie zakładaj przyczyny, jeśli nie wynika z danych.

Model działa lepiej, kiedy wie, jaki ma tryb pracy: ma analizować, a nie improwizować.

AI jako asystent, nie system monitoringu

AI może przyspieszyć triage, pomóc pisać raporty i porządkować kontekst. Nie zastąpi jednak monitoringu, retencji logów, alertów, dashboardów i podstawowej higieny operacyjnej.

Najlepszy układ to połączenie prostych narzędzi z modelem:

lokalne parsowanie i heurystyki,
monitoring i alerty dla zdarzeń powtarzalnych,
AI do opisu, korelacji i wsparcia analizy,
człowiek do decyzji i zmian w systemie.

Wtedy AI nie jest magicznym filtrem na chaos, tylko kolejnym narzędziem w dobrze ułożonym procesie.