Zbudowaliśmy system, który codziennie przegląda logi ponad 100 urządzeń sieciowych w naszej sieci operatorskiej i w sieci osiedlowej SM Stare Gliwice. Co rano administrator dostaje krótki raport napisany przez AI. Gdy dzieje się coś poważnego, w ciągu minuty przychodzi SMS, a zaraz po nim e-mail z odpowiedzią: co się stało, gdzie szukać i co sprawdzić najpierw.
Każdy switch, router i OLT codziennie zapisuje setki komunikatów: zmiany stanu portów, burze broadcastowe, logowania, restarty. Jedna linia potrafi zapowiedzieć awarię całego budynku. Przy ponad 100 urządzeniach nikt nie ma jednak czasu czytać tego ręcznie, więc do logów zagląda się dopiero po awarii, kiedy dzwonią klienci.
Do tego dochodzą wymagania ustawy o krajowym systemie cyberbezpieczeństwa i dyrektywy NIS2: monitorowanie, wykrywanie incydentów i dowody, że ktoś te dane rzeczywiście przegląda.
O tym, czy jest alarm, decydują sprawdzone reguły. Działają w sekundę, nic nie kosztują i nie zależą od żadnej zewnętrznej usługi. Sztuczna inteligencja (Claude firmy Anthropic) robi to, w czym jest najlepsza: czyta wyliczone fakty i fragmenty logów, zna topologię sieci i pisze po ludzku, co się dzieje. Dzięki temu system jest jednocześnie szybki, przewidywalny i zrozumiały.
Cztery warstwy, z których każda działa samodzielnie.
Wszystkie urządzenia wysyłają logi w jedno miejsce. Archiwum z 12 miesięcy z sumami kontrolnymi SHA-256 i 90 dni szybkiego wyszukiwania w Grafanie.
Skrypt porównuje każdą dobę z poprzednimi siedmioma: burze, pętle, flapy portów, logowania, restarty, zmiany konfiguracji i urządzenia, które nagle ucichły.
AI dostaje fakty, opis sieci i jej szkielet. Pisze raport do przeczytania w dwie minuty: Pilne, Do sprawdzenia, Informacyjnie.
Co minutę reguły sprawdzają nowe logi. Przy poważnym problemie od razu idzie SMS, a po około 30 sekundach e-mail z opisem od AI.
Zamiast setek linii kilka punktów z liczbami, godzinami i porównaniem ze średnią z ostatniego tygodnia. Rzeczy znane i normalne dla Twojej sieci pomija.
Co widać, jaka może być przyczyna, gdzie fizycznie szukać i od 2 do 4 konkretnych kroków na start. Wyraźnie oddziela fakty z logów od przypuszczeń.
Dostaje szkielet sieci zbudowany z LLDP. Wie, który port jest uplinkiem, który switch wisi pod którym i jaka droga prowadzi do rdzenia.
Po lewej przykładowy SMS przy alarmie pilnym. Po prawej prawdziwy e-mail z naszej sieci osiedlowej, skrócony, z uproszczonymi nazwami urządzeń.
SMS: alarm pilny (przykład)
Jedna wiadomość na problem, do 160 znaków, bez polskich znaków. Trwający alarm nie wysyła kolejnych SMS-ów.
E-mail: opis od AI, około 30 sekund po alarmie
Coś do sprawdzenia, nie awaria: monitoring dostępności milczy, ale burza przychodzi z góry, od strony switcha blokowego, a nie od klientów.
Najprostszy sposób, żeby administrator przestał czytać powiadomienia, to wysyłać ich za dużo. Dlatego alarmy mają dwa poziomy, a progi ustawiliśmy na prawdziwych logach z naszych sieci.
Zanim włączyliśmy SMS-y, puściliśmy reguły na archiwum z 9 dni. Pierwsza wersja wysłałaby 16 SMS-ów, z czego 11 o logowaniach samego administratora z adresów, których system jeszcze nie znał. Po dopisaniu zaufanych adresów i podziale na dwa poziomy zostało 0 SMS-ów i 6 e-maili. Reguły SMS sprawdziliśmy też na zasymulowanych awariach: pętli, lawinie STP, restartach w kółko i obcym logowaniu.
Rzeczy, które były w logach od dawna, tylko nikt ich nie zauważył.
Wielogodzinna burza broadcast na uplinku jednego ze switchy klatkowych. AI wskazało, że ruch przychodzi od strony switcha blokowego, i zasugerowało sprawdzenie zbyt nisko ustawionej ochrony na porcie.
Raport poranny zauważył, że jedno z urządzeń od kilku dni nie wysyła żadnych logów, choć wcześniej robiło to codziennie. Bez porównania z historią nikt by tego nie wyłapał.
Przy nieudanym logowaniu ktoś wpisał hasło w pole nazwy użytkownika i trafiło ono do logów. System maskuje takie wpisy w raportach, a administrator dostał sygnał, żeby to hasło zmienić.
94 nieudane logowania SNMP w 9 dni pochodziły z własnego narzędzia monitoringu, najpewniej przez źle ustawione dane dostępowe. Drobiazg, ale zaśmiecał logi i mógł zagłuszyć prawdziwy problem.
Model nie ma żadnych narzędzi. Nie loguje się na urządzenia i niczego nie zmienia. Dostaje tekst i odpowiada tekstem.
Hasła w logowanych poleceniach i nieznane nazwy użytkowników są maskowane, zanim cokolwiek opuści serwer.
Pełne archiwum leży na Twoim serwerze i w Twoich kopiach zapasowych. Do AI trafia tylko wycinek potrzebny do opisu.
Rozwiązanie sprawdza się wszędzie tam, gdzie urządzeń sieciowych są dziesiątki lub setki, a zespół IT jest mały.
Sieci FTTH, radiowe i Ethernet z routerami brzegowymi, OLT i dziesiątkami switchy dostępowych.
Sieci osiedlowe ze switchami w każdym budynku i klatce, gdzie pętla u jednego mieszkańca potrafi odciąć cały blok.
Organizacje, które muszą monitorować sieć, wykrywać incydenty i mieć na to dowody.
Działa z MikroTik, D-Link, TP-Link, HPE, Huawei i każdym urządzeniem, które potrafi wysłać syslog.
Spisujemy urządzenia i topologię. Ustalamy, co jest rdzeniem, co agregacją, a co dostępem.
Maszyna wirtualna lub kontener w Twojej infrastrukturze. Ustawiamy na urządzeniach wysyłkę logów i synchronizację czasu.
Szkielet sieci, adresy administratorów i lista rzeczy, które w Twojej sieci są normalne.
Zanim włączymy SMS-y, sprawdzamy na archiwum, ile powiadomień byś dostał, i stroimy progi.
Pełne logi zostają na Twoim serwerze. Do modelu AI trafiają tylko wyliczone fakty i krótkie, zamaskowane fragmenty potrzebne do opisu.
Oprogramowanie serwera logów jest otwarte i nie wymaga licencji. AI kosztuje kilka dolarów miesięcznie za raporty dzienne i mniej niż 0,10 USD za opis alarmu. SMS-y według cennika bramki SMS.
Nie. Model nie ma dostępu do urządzeń ani żadnych narzędzi. Czyta tekst i pisze tekst, a o alarmie decydują reguły.
Alarmy i raporty przychodzą dalej, tylko z samymi faktami zamiast opisu. Wykrywanie problemów nie zależy od AI.
Nie, uzupełnia je. Monitoring mówi, że coś przestało odpowiadać. Analiza logów mówi dlaczego: pętla, burza, restart albo obce logowanie.
Od 23:00 do 6:00 przychodzą tylko e-maile. SMS dostajesz rano, i to tylko wtedy, gdy pilny problem nadal trwa.
Kompleksowa obsługa informatyczna Regionalnej Izby Przemysłowo-Handlowej w Gliwicach - stacje robocze, serwery, bezpieczeństwo i bieżące wsparcie.
Zobacz realizację →Obsługa informatyczna · od 2018Stała administracja infrastrukturą IT spółdzielni mieszkaniowej - systemy biurowe, kopie zapasowe, opieka nad siecią i sprzętem.
Zobacz realizację →Sieci · od 2018Administrujemy osiedlową siecią LAN dla ok. 500 użytkowników i 130 zarządzalnymi urządzeniami sieciowymi - z redundancją BGP, monitoringiem i szkieletem 10 Gb/s.
Zobacz realizację →Serwer logów, raport dzienny pisany przez AI i alarmy SMS dla sieci operatorskich, osiedlowych i firmowych. Od przeglądu sieci, przez wdrożenie, po strojenie progów na Twoich logach.