Jak budować zestawy danych treningowych z logów systemowych i metryk sieci

Scena startowa: gdy model „nie widzi” awarii, choć logi krzyczą

Admin dyżurny dostaje w nocy lawinę alertów z monitoringu: rośnie latency, pojawiają się błędy 5xx, routery gubią pakiety. System logów aż się czerwieni, a model predykcyjny awarii, którym chwalono się na ostatnim zarządzie, milczy. Rano w raportach pojawia się pytanie: „co jest nie tak z tym waszym machine learningiem?”.

W takiej sytuacji odruchowo oskarża się algorytm: „model jest słaby”, „powinniśmy użyć sieci LSTM”, „może trzeba transformerów”. W praktyce źródło problemu zwykle leży wcześniej – w sposobie, w jaki zbudowano zestaw danych treningowych z logów systemowych i metryk sieci. Algorytm widział w historii głównie gładkie, uśrednione metryki, bez prawdziwych anomalii, albo etykiety były przesunięte w czasie o kilkanaście minut. Model uczył się czegoś innego niż tego, czego oczekuje od niego zespół.

Duże organizacje często mówią: „mamy mnóstwo logów, petabajty danych”. To wciąż jest daleko od „mamy dobrze zbudowany zbiór treningowy”. Surowe logi i metryki są jak stos nieposortowanych faktur – dopóki ktoś ich nie zindeksuje, nie ujednolici formatu, nie powiąże wpisów między systemami, nie da się na nich sensownie liczyć ani podejmować decyzji. Zestaw danych treningowych to właśnie ten etap: przekształcenie chaosu w spójną, tabelaryczną reprezentację, gdzie każda próbka ma jasną etykietę i zestaw sensownych cech.

Praktyka pokazuje, że jakość i struktura danych mają większy wpływ na skuteczność modelu ML niż wybór konkretnego algorytmu. Nawet prosty model logistyczny czy gradient boosting potrafi osiągać świetne wyniki, jeśli ma dobrze przygotowane okna czasowe, właściwie zdefiniowane etykiety anomalii, poprawnie złączone logi z wielu hostów i ustandaryzowane metryki sieciowe. Bez tego nawet najbardziej zaawansowana architektura modelu pozostanie ślepa na faktyczne sygnały nadchodzącej awarii.

Kluczowy wniosek z takich nocnych incydentów jest jeden: zanim padnie pytanie „jaki model wybrać?”, trzeba odpowiedzieć na dużo bardziej przyziemne, ale krytyczne pytanie – „czy zestaw danych treningowych faktycznie reprezentuje problem, który chcemy rozwiązać, i czy robi to w skali czasu odpowiadającej rzeczywistym incydentom?”.

Jakie problemy ML da się realnie rozwiązać na logach i metrykach

Logi systemowe i metryki sieci otwierają drogę do wielu zastosowań uczenia maszynowego, ale każde z nich wymaga innego podejścia do budowy zbioru treningowego. Zanim zacznie się wyciągać cechy, trzeba nazwać problem, inaczej zbiory danych będą chaotyczną mieszanką, z której nic sensownego nie wyjdzie.

Typowe przypadki użycia w środowiskach operacyjnych

Na bazie logów i metryk sieciowych najczęściej buduje się modele dla kilku typów zastosowań:

• Detekcja anomalii operacyjnych – wykrywanie nietypowych wzorców w ruchu, nagłych skoków błędów, podejrzanych sekwencji logów. Modele anomalii działają zwykle online, często w bliskim czasie rzeczywistym.
• Predykcja awarii i degradacji – przewidywanie, że w najbliższych minutach lub godzinach wzrośnie liczba błędów, spadnie przepustowość lub przestanie odpowiadać konkretny host lub usługa.
• Capacity planning – prognozowanie obciążenia (CPU, RAM, przepływność łączy, liczba zapytań) w przyszłości, aby lepiej planować zasoby i skalowanie.
• Wykrywanie nadużyć i incydentów bezpieczeństwa – identyfikacja nietypowych wzorców logowań, skanowań portów, prób włamań czy nadużyć API.
• Korelacja zdarzeń między systemami – uczenie modeli, które wskazują, jakie typy logów czy zjawisk metrycznych poprzedzają lub towarzyszą konkretnym incydentom (np. degradacji usługi końcowej).

Dla każdego z tych zastosowań inna jest definicja „normalności” i „problemu”, więc inne muszą być cechy, okna czasowe oraz sposób etykietowania zdarzeń. Zbiór danych do capacity planningu będzie korzystał głównie z długoterminowych agregacji metryk, natomiast model wykrywania skanowań portów oprze się na drobnoziarnistych, sekundowych lub milisekundowych próbkach.

Klasyfikacja, regresja i detekcja anomalii – różne wymagania na dane

Na tym samym źródle danych można postawić trzy różne typy problemów ML, a każdy wymaga innego przygotowania zbioru:

• Klasyfikacja binarna lub wieloklasowa – np. „czy w ciągu najbliższych 15 minut wystąpi awaria danego hosta (tak/nie)”. Potrzebne są jawne etykiety, czyli okresy oznaczone jako „awaria” i „brak awarii”. Kluczowe jest precyzyjne zdefiniowanie, co liczy się jako awaria, oraz ustalenie horyzontu czasowego predykcji.
• Regresja – np. „jaka będzie przepustowość łącza za 10 minut”, „jaki będzie średni czas odpowiedzi API za godzinę”. Etykietą jest tu wartość ciągła, obliczona z metryk w przyszłości. Trzeba przygotować okna czasowe z przeszłości i sparować je z wartością z przyszłości.
• Detekcja anomalii – często w formie uczenia bez nadzoru lub pół-nadzorowanego. Dane oznaczone są jako „normalne”, a anomalie są rzadkie i nie zawsze dobrze opisane. Tu szczególnie ważne jest rzetelne odfiltrowanie okresów awaryjnych ze zbioru treningowego, jeśli trenowany jest model „normalności”.

Skuteczne modele bezpieczeństwa często łączą te podejścia. Dla przykładu: model klasyfikacyjny może odróżniać „prawdopodobne skanowanie” od „zwykłego ruchu”, podczas gdy detektor anomalii wychwytuje nowe, wcześniej nieznane wzorce. W obu przypadkach bez sensownie zbudowanego zbioru treningowego z logów i metryk sieciowych algorytm nie odróżni realnych incydentów od zwykłych fluktuacji.

Skala czasu a konstrukcja próbek

Logi i metryki sieci działają na różnych skalach czasu:

• logi aplikacyjne: od pojedynczych milisekund (request/response) do minut (zadania batchowe),
• metryki sieci (SNMP, NetFlow): najczęściej w sekundach lub minutach, czasem z próbkowaniem w milisekundach,
• zdarzenia awarii i SLA: mierzone w minutach, godzinach, a nawet dniach.

Jeśli model ma przewidywać awarię, która typowo „dojrzewa” przez 20–30 minut (np. narastający memory leak), to próba trenowania go na oknach 5-sekundowych będzie bezsensowna: sygnał będzie ukryty w szumie krótkoterminowych fluktuacji. Z drugiej strony, model wykrywania ataków DDoS musi widzieć bardzo krótkie, intensywne wzrosty ruchu – więc wymaga gęstego próbkowania i okien rzędu sekund.

Dobranie jednostki przewidywania (czyli: co dokładnie model prognozuje i w jakiej skali czasu) jest bardziej krytyczne niż wybór konkretnej architektury. Zanim zacznie się budować pipeline, trzeba odpowiedzieć na pytania:

• czy prognozowany jest konkretny wskaźnik (np. opóźnienie, przepływność) czy zdarzenie (awaria, incydent bezpieczeństwa),
• jaki jest horyzont prognozy (minuty, godziny),
• jakiej rozdzielczości danych potrzebuje model, aby widzieć realne sygnały, a nie przypadkowy szum.

Bez tej decyzji każdy kolejny krok – od zbierania danych po inżynierię cech – będzie serią zgadywanek zamiast świadomym projektowaniem zbioru treningowego.

Rozumienie źródeł danych: logi systemowe vs metryki sieci

Budowanie zestawów danych treningowych z logów systemowych i metryk sieci wymaga potraktowania tych dwóch światów inaczej. Jeden to głównie tekstowe zdarzenia, drugi to numeryczne serie czasowe. Oba trzeba sprowadzić do wspólnego „języka”, zanim staną się użyteczne dla ML.

Różnice strukturalne między logami a metrykami

Logi systemowe to zazwyczaj zdarzenia tekstowe, generowane asynchronicznie przez:

• system operacyjny (syslog),
• serwery aplikacyjne,
• bazy danych,
• urządzenia sieciowe (firewalle, load balancery),
• komponenty bezpieczeństwa.

Każdy wpis logu reprezentuje pojedyncze zdarzenie: „użytkownik X się zalogował”, „połączenie do hosta Y zostało odrzucone”, „aplikacja zgłosiła błąd”. Struktura bywa częściowo ustandaryzowana (np. syslog), ale często zawiera nieregularne wiadomości tekstowe. Typowe pola, które są kluczowe dla ML, to:

• timestamp – czas zdarzenia,
• host/source – nazwa hosta, adres IP, identyfikator urządzenia,
• facility / typ logu – np. auth, kernel, application, firewall,
• level – DEBUG, INFO, WARN, ERROR, CRITICAL,
• message – właściwy tekst zdarzenia, często z dodatkowymi polami (np. kod błędu, user agent, numer portu).

Metryki sieciowe z kolei mają postać serii czasowych:

• zliczenia pakietów i bajtów (SNMP, NetFlow/sFlow),
• opóźnienia, jitter, utrata pakietów (metryki jakości połączeń),
• liczba aktywnych połączeń, sesji, połączeń TCP w danym stanie,
• metryki aplikacyjne eksportowane do Prometheusa (np. liczba żądań HTTP, histogramy czasów odpowiedzi).

To dane numeryczne, z próbkowaniem w ustalonych odstępach (np. co 15 sekund, co minutę). Surowe logi można uznać za ciąg nieregularnych zdarzeń, metryki są natomiast regularnie próbkowaną funkcją czasu. Dla uczenia maszynowego trzeba je sprowadzić do wspólnej osi czasu i formy tabelarycznej.

Najczęstsze źródła danych operacyjnych

W typowym środowisku produkcyjnym spotyka się kilka klas źródeł, z których buduje się później zbiór treningowy:

• Syslog – logi systemu operacyjnego, demonów, usług sieciowych. Często w formacie tekstowym, zbierane do centralnego syslog-ng lub rsyslog.
• Logi aplikacyjne – Nginx/Apache, serwery aplikacyjne (Tomcat, Node.js, .NET), aplikacje biznesowe pisane wewnętrznie, często w JSON lub logfmt.
• Firewalle i IDS/IPS – logi odrzuconych połączeń, reguł bezpieczeństwa, wykrytych sygnatur, z informacjami o IP, porcie, protokole.
• Load balancery i reverse proxy – logi żądań HTTP, sticky sessions, błędów połączeń do backendów.
• SNMP – podstawowe metryki urządzeń sieciowych (interfejsy, CPU, pamięć).
• NetFlow/sFlow/IPFIX – przepływy sieciowe opisujące komunikację między adresami IP, portami, protokołami.
• Prometheus / TSDB – bazujące na time-series rozwiązania do zbierania metryk aplikacyjnych i systemowych.

Kluczem jest zrozumienie, które pola z tych źródeł są stabilne i wiarygodne jako klucze łączenia (np. IP, nazwa hosta), a które są zbyt niestandardowe lub podatne na zmiany (np. dynamiczne identyfikatory kontenerów). Przy projektowaniu zbioru treningowego lepiej opierać się na polach, które będą dostępne i spójne także w przyszłości.

Ujednolicenie czasu i identyfikatorów hostów

Najczęstszą, podstępną przeszkodą przy łączeniu logów i metryk sieci jest niespójność timestampów i stref czasowych. Przykładowe problemy:

• różne systemy używają różnych formatów daty (ISO 8601, format syslog, własne konwencje),
• część logów zawiera strefy czasowe, inne nie,
• serwery mają źle zsynchronizowany czas (brak NTP, dryf zegara),
• timestamp logu oznacza czas zapisu, niekoniecznie czas faktycznego zdarzenia (np. w systemach kolejkowych).

Jeśli różnice sięgają minut, to na poziomie budowy zbioru treningowego model będzie dostawał cechy, które odpowiadają innemu fragmentowi rzeczywistości niż etykieta (awaria). Będzie to działać jak losowe zakłócenie, wyraźnie obniżając jakość predykcji. Dlatego już na poziomie pipeline’u warto wdrożyć:

• obowiązkową synchronizację czasu przez NTP,
• standaryzację timestampów do jednego formatu (najlepiej UTC + ISO 8601),
• weryfikację dryfu czasu między źródłami (np. przez korelację znanych zdarzeń w logach).

Normalizacja i mapowanie kontekstu infrastruktury

Administrator patrzy na dashboard: ten sam serwer w jednym systemie nazywa się web-01, w drugim prod-front-a, a w logach aplikacyjnych występuje tylko jako ID kontenera. Model ma „widzieć” jedną maszynę, a zamiast tego dostaje trzy różne byty. Zanim jakikolwiek algorytm zrozumie, co się dzieje w sieci, trzeba nauczyć dane mówić jednym językiem.

Przy budowaniu zbioru treningowego nie wystarczy złączyć logów i metryk po czasie. Potrzebne jest także spójne odwzorowanie elementów infrastruktury – serwerów, usług, interfejsów sieciowych – na stabilne identyfikatory, które przetrwają zmiany w konfiguracji.

• Mapowanie hostów – nazwy serwerów, ID instancji w chmurze, nazwy kontenerów i adresy IP trzeba zmapować do jednej, wewnętrznej reprezentacji (np. asset_id z CMDB lub innego rejestru). Ta warstwa powinna żyć poza logami; logi jedynie odnoszą się do niej kluczami.
• Topologia sieci – warto przechowywać informację, do jakiego segmentu sieci, VLAN-u, strefy bezpieczeństwa należy dany adres IP. Te dane są później świetnymi cechami: model może inaczej traktować ruch z DMZ niż z sieci biurowej.
• Relacje usługa–host – ta sama usługa może migrować między hostami (rolling deployment, autoscaling). W cechach lepiej opisywać zarówno konkretne IP/hosta, jak i logiczny identyfikator usługi (np. service_name z discovery / service mesh).

Sensowną praktyką jest wydzielenie w pipeline’ie kroku „enrichment”, który przed zapisaniem do hurtowni danych dodaje:

• globalny asset_id,
• klasyfikację strefy (np. zone=prod/public, zone=office),
• atrybuty techniczne (typ urządzenia, rola: db, web, cache),
• informację o środowisku (env=prod/stage/dev).

Później, przy konstruowaniu zestawu treningowego, te pola pozwalają budować cechy na wyższym poziomie abstrakcji i uniknąć dopasowywania modelu do przypadkowych nazw hostów czy dynamicznych IP.

Standaryzacja schematów logów i metryk

Przy pierwszym podejściu do budowy zbioru treningowego okazuje się, że każda aplikacja loguje po swojemu: raz pole z adresem IP to client_ip, raz remote_addr, a raz jest wciśnięte w surowy tekst. Metryki z Prometheusa mają label instance, SNMP używa ifIndex. Bez ujednolicenia schematu każdy krok analizy zamienia się w kolekcję wyjątków.

Dobrym wzorcem jest zdefiniowanie wewnętrznego modelu zdarzenia i metryki, do którego wszystkie źródła są mapowane. Nie musi to być od razu kompletny standard, ale dobrze, jeśli:

• logi posiadają wspólny zestaw pól bazowych (np. @timestamp, asset_id, service, severity, category, message),
• metryki mają jednolitą strukturę: timestamp, metric_name, value, labels (zestaw klucz–wartość).

Transformacje mogą wyglądać prosto, ale muszą być konsekwentne:

• parsing tekstu (regex, grok, JSON) do pól strukturalnych,
• mapowanie nazw pól z poszczególnych aplikacji do wspólnych nazw (np. src_ip, dst_ip, url_path),
• normalizacja kategorii (np. różne typy błędów mapowane na ogólne klasy: auth_failure, db_error, timeout).

Jeśli schemat jest spójny, budowanie cech sprowadza się do statystyk po tych polach, a nie do ciągłego „jeżeli aplikacja X, to weź pole A, w przeciwnym razie B”. Mniej „ifów” w kodzie oznacza mniej cichych błędów w zbiorze treningowym.

Od strumienia zdarzeń do tabeli cech

Inżynier siada do notebooka, pobiera logi HTTP z całego tygodnia i szybko buduje prosty model. Wszystko wygląda dobrze, dopóki nie spróbuje odtworzyć tego samego wyniku miesiąc później – wtedy wychodzi na jaw, że każdorazowo dane przygotowywane są inaczej. Trzeba więc zamienić pojedynczy eksperyment w powtarzalny proces konstrukcji tabeli cech.

Okna czasowe i agregacja zdarzeń

Modele operujące na logach i metrykach rzadko kiedy pracują na pojedynczych zdarzeniach. Zazwyczaj kluczowe są wzorce w czasie: wzrost liczby błędów, skoki w wolumenie ruchu, kumulacja nieudanych logowań. To wymusza zdefiniowanie okien czasowych, w których logi i metryki są agregowane.

Najpierw trzeba zdecydować, jaki typ okien ma sens dla danego problemu:

• Okna stałej długości (tumbling windows) – np. co 1 minutę, co 5 minut. Dobre dla klasyfikacji „czy w tym oknie występuje anomalia”.
• Okna przesuwne (sliding windows) – np. co 1 minutę z długością okna 10 minut. Umożliwiają „gładkie” obserwowanie trendów, kosztem większej liczby próbek.
• Okna skoncentrowane wokół zdarzenia – np. 30 minut przed awarią, 10 minut po restarcie usługi. Stosowane przy problemach typu „co dzieje się przed / po incydencie”.

W każdym oknie dane są redukowane do zestawu statystyk. Dla logów HTTP mogą to być m.in.:

• liczba żądań ogółem i per metoda (GET/POST/…),
• liczba odpowiedzi 2xx/4xx/5xx, proporcje błędów,
• liczba unikalnych IP źródłowych,
• najczęściej odwiedzane ścieżki URL (ograniczone do top N).

Dla metryk sieciowych w podobnym oknie czasowym można policzyć:

• średni, minimalny i maksymalny ruch (bajtów/s, pakietów/s),
• średnie opóźnienie, jitter, utratę pakietów,
• liczbę aktywnych połączeń, liczbę nowych połączeń,
• tempo zmian – różnicę między początkiem i końcem okna (trend).

Wnioski z praktyki są proste: lepiej zacząć od mniejszej liczby dobrze przemyślanych okien (np. 1, 5, 15 minut), niż budować od razu kilkanaście skal czasowych, których potem nikt nie zinterpretuje. Gdy model pokaże, w jakich horyzontach „coś widzi”, można dodawać kolejne.

Łączenie logów i metryk w jedną próbkę

Przy realnych incydentach sieciowych logi i metryki rzadko „krzyczą” w tym samym miejscu. Log wskazuje błąd w aplikacji, metryka – nagły wzrost opóźnień. W zbiorze treningowym trzeba je jednak sprowadzić do jednej, spójnej obserwacji.

Typowa próbka dla modelu może wyglądać tak:

• indeks: (asset_id, window_start) – host/usługa i początek okna czasowego,
• cechy z logów: statystyki błędów, liczby zapytań, liczba logowań, rozkład kodów odpowiedzi, liczba wyjątków,
• cechy z metryk: obciążenie CPU, pamięć, I/O, ruch na interfejsach, liczba połączeń w różnych stanach,
• etykieta: np. failure_within_30m (0/1) lub latency_next_10m (wartość ciągła).

Łączenie odbywa się w dwóch krokach:

1. Agregacja per źródło – najpierw w każdym źródle (np. logi HTTP, logi systemowe, metryki Prometheusa) powstaje tabela: wiersz na (asset_id, window_start), kolumny – zagregowane cechy.
2. Join po wspólnym kluczu – następnie tabele z różnych źródeł są łączone lewym złączeniem po (asset_id, window_start). Braki w danych dla niektórych źródeł trzeba jawnie obsłużyć (wypełnianie zerami, wartościami domyślnymi lub osobnymi kategoriami).

W praktyce najwięcej problemów robi nie samo JOIN, ale spójność asset_id i definicja okna czasowego. Jeśli te elementy są ustalone i dobrze przetestowane, reszta jest mechaniką SQL lub kodu ETL.

Radzenie sobie z brakującymi danymi i lukami w metrykach

Podczas incydentu monitoring bywa najbardziej zawodnym elementem: agenty przestają raportować, TSDB jest przeciążone, a logi nie są dosyłane na czas. Dokładnie wtedy, gdy dane są najbardziej interesujące, pojawiają się dziury. Zamiatanie ich pod dywan niszczy jakość zbioru treningowego.

Przy projektowaniu pipeline’u trzeba jasno określić politykę obsługi braków:

• Jawne flagi braków – zamiast zgadywać, co oznacza 0 w metryce, lepiej dodać cechę metric_missing=1 i zostawić wartość numeryczną jako NULL lub specjalną wartość (np. -1). Model może wtedy sam nauczyć się, że „brak danych z agenta” bywa sygnałem problemów.
• Imputacja ostrożna, nie agresywna – interpolacja liniowa na krótkich lukach (np. 1–2 próbki) ma sens przy metrykach ciągłych; przy dłuższych lukach lepiej zaznaczyć brak niż udawać ciągłość.
• Filtrowanie zbyt ubogich okien – jeśli w danym oknie brakuje większości kluczowych metryk, taka próbka może bardziej szkodzić niż pomagać. Można ją odrzucić albo oznaczyć osobną etykietą „dane niepewne”.

Prosty, lecz skuteczny zabieg: dodać do zbioru treningowego cechy zliczające ile metryk faktycznie dotarło w danym oknie. Modele sekwencyjne czy drzewiaste bardzo często wykorzystują informację „dziura w monitoringu” jako element wzorca awarii.

Inżynieria cech z logów tekstowych

Podczas incydentu bezpieczeństwa SOC widzi w konsoli ścianę komunikatów z firewalla i IDS-a. Człowiek wyłapuje słowa-klucze i zależności między nimi, model na surowym tekście zobaczy tylko ciąg znaków. Trzeba wyciągnąć z logów strukturę, której da się użyć jako cech.

Tokenizacja, szablony logów i redukcja wariantów

Większość logów aplikacyjnych to powtarzające się wzorce z niewielkimi różnicami (ID użytkownika, ścieżka, parametry). Dobrym krokiem jest ekstrakcja szablonów logów, czyli sprowadzenie wielu różnych komunikatów do jednego typu zdarzenia.

Przykład:

• ERROR User 123 failed to login from 10.0.0.1
• ERROR User 987 failed to login from 10.0.0.2

Po parsingu i uogólnieniu mogą zostać zapisane jako:

• szablon: ERROR User <id> failed to login from <ip>
• pola: user_id, src_ip, severity=ERROR, event_type=auth_login_failed.

Do automatycznego wykrywania szablonów istnieją algorytmy (np. Drain, Spell), ale w wielu środowiskach wystarczy prosty zestaw reguł i ręcznie utrzymywany słownik zdarzeń. Najważniejsze, aby:

• liczba unikalnych typów logów była ograniczona (setki, nie setki tysięcy),
• każdy typ miał stabilny, opisowy event_type,
• parametry zmienne (ID, IP, porty) były wyciągane do osobnych pól.

W tabeli cech można potem używać zarówno statystyk po typach zdarzeń (np. liczba auth_login_failed w oknie), jak i informacji o rozkładzie ich parametrów (liczba unikalnych użytkowników, unikalnych źródłowych IP).

Cecha „gęstość zdarzeń” i tempo zmian

Człowiek czytający logi intuicyjnie widzi, kiedy „coś się dzieje”: logi zaczynają „przewijać się” szybciej. Modelowi trzeba tę intuicję przetłumaczyć na liczby.

Przydatna rodzina cech to miary gęstości i dynamiki:

• liczba zdarzeń na jednostkę czasu (np. logi na sekundę, błędy na minutę),
• pochodne w czasie – przyrost liczby zdarzeń względem poprzedniego okna (delta_events),
• stosunki – np. błędy do wszystkich żądań (error_rate), nieudane logowania do wszystkich logowań,
• entropia typów zdarzeń – czy w oknie dominuje jeden typ, czy mamy dużą różnorodność.

Ekstrakcja encji z logów i budowanie cech „kontekstowych”

Podczas analizy większego ataku DDoS analityk często nie patrzy na pojedynczy komunikat, tylko na to, kto go wygenerował i skąd przyszedł ruch. To nie linijka logu jest kluczowa, tylko kontekst: adresy IP, konta, hosty, kraje. Dokładnie tak samo powinien działać zestaw danych do trenowania modeli.

Po zbudowaniu szablonów logów kolejnym krokiem jest ekstrakcja encji – spójnych obiektów, które pojawiają się w wielu komunikatach:

• adresy IP (źródłowe / docelowe),
• identyfikatory użytkowników / kont,
• identyfikatory sesji, tokenów,
• nazwy hostów, mikroserwisów, interfejsów.

Te elementy można wykorzystać w cechach na kilka sposobów:

• liczność i unikalność encji – liczba unikalnych IP, liczba użytkowników w oknie, liczba sesji na użytkownika,
• kierunkowość – liczba różnych docelowych hostów, do których łączy się dany src_ip w oknie,
• kumulacja historii – ile razy dany użytkownik miał nieudane logowanie w ostatnich N godzinach, liczba incydentów związanych z tym adresem IP w poprzednim dniu.

Prostym trikiem jest trzymanie pomocniczych tabel z historią encji (np. „profil” IP lub użytkownika) i łączenie ich z oknami czasowymi po kluczach. Dzięki temu w jednej próbce model „widzi” nie tylko bieżący zryw ruchu, ale też to, że adres IP od tygodnia co noc skanuje jeden z segmentów sieci.

Uproszczone reprezentacje tekstu: słowniki, n-gramy, embeddingi

Czasem logi są zbyt zróżnicowane, aby zdać się wyłącznie na szablony. Przykład: komunikaty błędów aplikacji z długimi stack trace’ami, statusami biznesowymi, różnymi językami. W takich przypadkach przydaje się dodatkowa, „miękka” reprezentacja tekstu.

Najczęściej używane podejścia to:

• worki słów / n-gramy – znormalizowany słownik (po usunięciu liczb, ID, bardzo rzadkich tokenów) i liczenie częstości wystąpień słów lub par słów w oknie,
• embeddingi zdaniowe – przejście z całego komunikatu logu na gęsty wektor (np. kilkadziesiąt wymiarów) otrzymany z modelu językowego, potem uśrednianie embeddingów w ramach okna,
• specjalne słowa-klucze – słownik słów „alarmowych” (np. denied, timeout, REFUSED) i cecha binarna lub licznik ich wystąpień.

Pełny model NLP na logach rzadko jest potrzebny od razu. W praktyce dobrze działają:

• proste wektory binarne (czy w oknie pojawiło się jakieś słowo z danej kategorii),
• małe embeddingi zredukowane PCA lub autoenkoderem, dołączone jako kilka dodatkowych kolumn.

Istotny jest kompromis między mocą reprezentacji a złożonością pipeline’u. Im trudniej będzie zreprodukować transformacje tekstu za pół roku, tym większe ryzyko, że zbiór treningowy stanie się nieaktualny przy kolejnej wersji systemu logowania.

Inżynieria cech z metryk sieciowych

Podczas awarii łącza NOC-owiec widzi kilka wykresów: przepustowość, opóźnienie, błędy interfejsu. Model widzi tysiące punktów czasowych, które – bez obróbki – są zwykłymi liczbami. Prawdziwa wartość kryje się w relacjach między nimi.

Cechy relacyjne między interfejsami i hostami

Sieć rzadko jest jedną liczbą „ruch w Mb/s”. Na ogół jest grafem: routery, przełączniki, serwery, load balancery. Część problemów da się wychwycić tylko wtedy, gdy cechy uwzględniają relacje między elementami.

Przykładowe cechy relacyjne:

• proporcje ruchu – udział ruchu danego interfejsu w całkowitym ruchu na routerze,
• asymetria – różnica między ruchem „upstream” i „downstream” na parze interfejsów,
• balansowanie obciążenia – rozkład ruchu między członkami grupy LAG/port-channel,
• korelacja opóźnień – współzmienność RTT między kilkoma ścieżkami do tego samego celu.

Z technicznego punktu widzenia oznacza to dodatkowy etap agregacji: metryki są grupowane nie tylko po asset_id, ale także po logicznych grupach (router, klaster, segment sieci) i dopiero na tej podstawie powstają cechy typu „udział”, „różnica”, „odchylenie od średniej grupy”.

Cechy opisujące stabilność i jitter metryk

Awaria nie zawsze objawia się skokiem wartości. Często wcześniejszym sygnałem jest „rozchwianie” metryk – większe wariancje, nagłe krótkie piki, rosnący jitter. Ludzkie oko je widzi, ale dla modelu trzeba to nazwać liczbami.

W oknie czasowym dla każdej z metryk warto policzyć oprócz średniej i maksimum także:

• odchylenie standardowe i współczynnik zmienności (odchylenie / średnia),
• liczbę przekroczeń progu – ile razy opóźnienie przekroczyło ustalony próg SLA,
• liczbę krótkich pików – ile razy metryka nagle wzrosła i szybko spadła (wykrywane np. prostą filtracją medianową),
• miary gładkości – suma modułów różnic między kolejnymi próbkami (im większa, tym bardziej „szarpana” seria).

Dzięki takim cechom model jest w stanie odróżnić „wyższy, ale stabilny ruch po migracji” od „ciągłego szarpania opóźnień przed awarią operatora”.

Agregacja wzdłuż ścieżek sieciowych

W wielu organizacjach istnieje chociaż częściowa mapa ścieżek sieciowych: które routery i przełączniki obsługują dany serwis, którędy przechodzi ruch do konkretnego data center. Taką wiedzę da się przełożyć na cechy.

Prosty schemat:

1. zidentyfikować dla danego serwisu listę interfejsów / urządzeń na krytycznej ścieżce,
2. przy agregacji okna dodać cechy typu: średnie opóźnienie „po drodze”, suma błędów CRC wzdłuż ścieżki, liczba przełączników z przekroczonym progiem wykorzystania,
3. zbudować osobne cechy dla „ścieżki głównej” i „ścieżek zapasowych”.

Nawet jeśli topologia nie jest w pełni udokumentowana, można zacząć od przybliżeń: pary (load balancer – backend), (VPN gateway – serwer aplikacyjny), segmenty VLAN. Każde takie połączenie pozwala modelowi lepiej rozumieć, że „opóźnienie rośnie wszędzie za tym konkretnym przełącznikiem”.

Łączenie cech czasowych z informacją o topologii

Podczas poważniejszej awarii inżynier często rysuje na kartce schemat: tu klient, tu router brzegowy, dalej tunel VPN, potem firewall i na końcu aplikacja. Z czasem przybywa strzałek i notatek. Zbiór treningowy też może mieć w sobie część tej topologii, zamiast być płaską tabelą.

Reprezentacja topologii jako cech

Nie zawsze potrzebne są wyrafinowane grafowe sieci neuronowe. W wielu przypadkach wystarczą proste cechy, które zakodują minimalną strukturę sieci:

• poziom w hierarchii – czy asset jest brzegowy, dystrybucyjny, dostępowy, czy aplikacyjny,
• liczba sąsiadów – ile ma sąsiednich urządzeń / peerów BGP / serwerów backendowych,
• stopień centralności – przybliżona liczba serwisów zależnych od danego urządzenia (np. liczba VIP na tym LB, liczba VLAN-ów na przełączniku),
• rodzaj łącza – lokalne, WAN, VPN, internet, chmura prywatna/publiczna.

Takie cechy mogą być statyczne (pobierane z CMDB, Ansible, Terraform) i łączone z oknami czasowymi tak samo jak metryki. Model uczy się wtedy, że awaria elementu centralnego jest „droższa” niż pojedynczego hosta, więc warto patrzeć na inne wzorce.

Proste cechy grafowe bez zaawansowanego GNN

Dla części zastosowań da się zbudować namiastkę cech grafowych, dalej korzystając z klasycznych modeli tablicowych:

• agregaty po sąsiadach – średnie i maksimum z metryk sąsiadów (np. średnie opóźnienie na wszystkich interfejsach sąsiadujących z tym routerem),
• kontrast z sąsiadami – różnica między metryką hosta a średnią metryką sąsiadów (np. cpu_host - avg_cpu_neighbors),
• liczba sąsiadów w stanie „alarmowym” – ile powiązanych urządzeń ma przekroczone progi alertów w oknie.

Technicznie wymaga to posiadania tabeli krawędzi (kto z kim jest połączony) i dodatkowego etapu agregacji (self-join lub przetwarzanie w narzędziu typu Spark/Beam). W zamian model dostaje sygnał: „ten host jest gorący na tle otoczenia” lub „wszędzie dookoła jest źle, więc to pewnie problem wyżej w topologii”.

Etykietowanie danych z incydentów

Największe zaskoczenie przy budowie modeli z logów i metryk często przychodzi nie z samego przetwarzania danych, tylko z etykiet. Zespół SRE ma setki alertów w PagerDuty, SOC – dziesiątki incydentów w SIEM-ie, a po połączeniu z oknami czasowymi nagle brakuje spójnych 0/1.

Źródła prawdy: systemy zgłoszeń, alerting, SIEM

Etykieta „tu był problem” rzadko żyje w jednym miejscu. Zwykle trzeba ją poskładać z kilku systemów:

• system ticketowy (Jira, ServiceNow) – incydenty, problemy, zmiany,
• system alertów (Prometheus Alertmanager, PagerDuty, Opsgenie),
• SIEM / SOAR – incydenty bezpieczeństwa, korelacje alertów,
• czasem: ręczne notatki z retrospektyw lub wiki.

Podstawowe zadanie to uzgodnić oś czasu i identyfikatory zasobów. Dla każdego incydentu trzeba określić:

• czas rozpoczęcia i zakończenia (lub przybliżenia),
• listę dotkniętych zasobów (hosty, serwisy, segmenty sieci),
• typ incydentu (awaria, degradacja, atak, błąd konfiguracji, prace planowe).

Na tej podstawie okna (asset_id, window_start) można oznaczyć jako:

• incident_active=1, gdy okno pokrywa się z trwającym incydentem,
• pre_incident=1, gdy znajduje się w zadanym buforze przed incydentem (np. 30 minut),
• post_incident=1, dla okien po zakończeniu (np. do analizy czasu powrotu do normy).

Etykiety do prognozowania, wykrywania i klasyfikacji

Ten sam zbiór logów i metryk może zasilać różne typy modeli, ale wymaga odmiennych etykiet. Kluczowe jest na początku zdefiniowanie, co model ma robić:

• wykrywanie anomalii / incydentów – etykieta binarna: czy w tym oknie (lub tuż po nim) wystąpił incydent,
• prognozowanie degradacji – etykieta ciągła, np. średnie opóźnienie / error rate w kolejnym oknie,
• klasyfikacja typu incydentu – etykieta wieloklasowa (atak DDoS, błąd konfiguracji, awaria sprzętowa, problemy z DNS),
• szacowanie wpływu – np. przewidywana liczba użytkowników dotkniętych problemem lub estymowany czas trwania.

Dobrym nawykiem jest tworzenie osobnych kolumn etykiet dla różnych zadań i nieprzeciążanie jednej flagi znaczeniami typu „1 = jakikolwiek problem”. Takie uproszczenie szybko zemści się przy próbie trenowania bardziej wyspecjalizowanych modeli.

Obsługa niejednoznacznych i częściowo opisanych incydentów

W rzeczywistości wiele zdarzeń nie ma idealnie oznaczonego początku, końca ani wpływów. Część incydentów jest opisana bardzo ogólnie („wolne logowanie do VPN”), a część w ogóle nie trafia do systemu. Zamiast udawać, że wszystko jest pewne, lepiej tę niepewność zakodować.

Kilka praktycznych technik:

• etykieta pewności – dodatkowa kolumna z prostą skalą: label_confidence ∈ {low, medium, high} lub wartość liczbową,