Jak AI czyta alerty z Zabbix i Grafany i co robi z historią incydentów w firmie?

Zabbix, Grafana i Prometheus mają otwarte API. AI może czytać stamtąd alerty, metryki i historię zdarzeń bez żadnej ingerencji w konfigurację monitoringu. W praktyce wygląda to tak: agent AI pobiera listę aktywnych triggerów z Zabbix API, sprawdza wyniki zapytań PromQL w Prometheusie i wyciąga adnotacje z Grafany, a potem z tego zestawu danych robi rzeczy, które administrator IT robił ręcznie: streszcza noc, grupuje alerty mające wspólne źródło i pisze gotowy wpis do rejestru incydentów.

Co Zabbix, Grafana i Prometheus wiedzą o Twojej infrastrukturze?

Zanim wejdzie AI, warto wiedzieć, z jakimi danymi mamy do czynienia. Zabbix zbiera metryki w tak zwanych items: obciążenie CPU, zużycie RAM, IOPS dysku, opóźnienie pinga, dostępność portów. Gdy któryś item przekroczy skonfigurowany próg, Zabbix tworzy trigger i zapisuje event z dokładnym znacznikiem czasu w polu event.clock. Każdy event ma przypisany status (PROBLEM lub OK) i severity: Information, Warning, Average, High, Disaster.

Grafana sama w sobie metryk nie zbiera, ale łączy się ze źródłami: Prometheusem, InfluxDB, Zabbix, Elasticsearch. Jej API udostępnia alert rules oraz annotations, czyli adnotacje, które administrator mógł ręcznie wpisać na wykres podczas zdarzenia. Tam często siedzi ludzki komentarz: "wgrywano nową wersję aplikacji" albo "serwer był restartowany". Bezcenny kontekst.

Prometheus przechowuje metryki jako szeregi czasowe. Można go zapytać przez PromQL o dowolny przedział: ile razy CPU przekraczało 90% przez ostatnie 7 dni, jak rósł rozmiar partycji /var/log w ciągu miesiąca, kiedy zaczął wydłużać się czas odpowiedzi bazy. Endpoint /api/v1/query_range zwraca gotowe dane do analizy.

Jak AI się podłącza, nie ruszając Twojego monitoringu?

Połączenie jest wyłącznie odczytem. W Zabbix tworzy się osobnego użytkownika z uprawnieniami Read (w sekcji User roles: Zabbix User) bez prawa do edycji konfiguracji. Agent AI dostaje token i wywołuje metody API: trigger.get, event.get, history.get i host.get. Nie zmienia triggerów, nie kasuje eventów, nie dotyka żadnego hosta.

W Grafanie zakłada się Service Account z rolą Viewer i generuje token. Stamtąd AI korzysta z endpointów /api/alerts i /api/annotations. Prometheus nie wymaga autoryzacji w podstawowej konfiguracji, ale można to ograniczyć przez reverse proxy z tokenem Bearer.

Typowo wygląda to tak, że agent odpytuje te trzy źródła raz na kilka minut albo reaktywnie, gdy pojawia się nowy alert o severity High lub Disaster. Dane trafiają do modelu językowego, który ma kontekst: wie, które hosty to produkcja, a które staging, zna imiona osób dyżurnych z kalendarza on-call i wie, jak wygląda normalny profil obciążenia w tej konkretnej firmie.

Streszczenie nocy: jeden akapit zamiast 60 maili

To jest ta rzecz, którą administratorzy lubią najbardziej. Standardowo rano w skrzynce czeka kilkadziesiąt wiadomości z Zabbix: każdy trigger, każde przejście PROBLEM na OK, każda zmiana severity. Ktoś musi przez to przebrnąć i ocenić, czy cokolwiek faktycznie wymaga uwagi. Przy spokojnej nocy i tak.

AI robi z tego jedno streszczenie. Przykład z jednego z naszych wdrożeń: administrator przychodzi rano i zamiast 60 maili widzi w Slacku taki komunikat: "W nocy między 02:15 a 04:47 serwer srv-prod-03 wygenerował 23 alerty o severity Average i High. Wspólnym źródłem był trigger Disk I/O latency > 80ms na partycji /var/data, który uruchomił kaskadę: przekroczenie czasu zapytań MySQL (trigger MySQL slow query rate > 10/s), błędy timeoutu backupu (job backup-prod-nightly) i wyczerpanie puli połączeń Apache. Wszystkie eventy zamknęły się o 04:47. Nie ma otwartych problemów."

Taki akapit administrator czyta w 20 sekund. Albo kierownik techniczny, który nie jest administratorem, ale chce wiedzieć, czy noc minęła spokojnie.

Grupowanie alertów z jednej przyczyny

Monitoring generuje osobny alert na każdy trigger, który zadziałał. Gdy pada serwer bazodanowy, Zabbix wysyła naraz kilka zdarzeń:

• trigger MySQL: Connection refused na hoście db-prod-01
• trigger Application response time > 30s na app-prod-01 i app-prod-02
• trigger Health check failed na load balancerze
• trigger Backup job: Last run status is not OK
• trigger ICMP ping response time is too high na monitorze zewnętrznym

Pięć osobnych alertów, jeden problem. AI nie potrzebuje do tego nic specjalnego. Widzi timeline eventów przez pole event.clock, widzi, że pierwszy trigger zapalił się na db-prod-01, a reszta z opóźnieniem kilku sekund na serwerach, które z niego korzystają. Grupuje je i oznacza jako "prawdopodobna przyczyna: baza danych na db-prod-01". Osoba dyżurna od razu wie, gdzie patrzeć.

Bez tego grupowania każdy z tych alertów ląduje osobno na ekranie. Ktoś musi ręcznie zestawić timeline i domyślić się, co było przyczyną, a co skutkiem. W środku nocy nie jest to przyjemne ćwiczenie.

Wykrywanie trendu przed awarią

To jest to, czego monitoring sam w sobie nie robi. Zabbix i Prometheus zbierają dane, ale nie piszą: "za dwa tygodnie zabraknie miejsca na dysku". AI może.

Agent pobiera dane historyczne przez history.get z zakresem 30 dni albo PromQL z dłuższym oknem i sprawdza, czy jakaś metryka rośnie w regularnym tempie. Najczęstsze przypadki, które wyłapujemy w ten sposób:

• partycja /var/log rośnie stale, bo logi nie są rotowane i za kilkanaście dni skończy się miejsce
• zużycie pamięci przez jeden z procesów rośnie powoli, co sugeruje wyciek (RSS systematycznie w górę, garbage collection nie pomaga)
• liczba błędów 5xx w logach aplikacji (metryka custom w Prometheusie, typ counter) rośnie tydzień po tygodniu mimo braku incydentów
• czas odpowiedzi bazy danych w godzinach szczytu jest wyraźnie wyższy niż trzy tygodnie temu, choć trigger jeszcze nie zadziałał

AI nie stawia diagnozy technicznej. Mówi: "ta metryka zachowuje się inaczej niż miesiąc temu, warto sprawdzić". Administrator decyduje, co z tym zrobić. Ale dostaje sygnał, zanim coś się posypie.

Gotowy wpis do rejestru incydentów

Wiele firm prowadzi rejestr incydentów: dla RODO, dla ISO 27001, dla audytorów albo po prostu dla własnego porządku. Wypełnianie go ręcznie po każdym zdarzeniu jest uciążliwe i często odkładane, przez co rejestr bywa niekompletny.

AI przygotowuje szkic wpisu od razu po zamknięciu incydentu. Wypełnia pola, które ma z danych monitoringu:

• Data i godzina rozpoczęcia: z pola event.clock pierwszego triggera w grupie
• Data i godzina zakończenia: z pola r_clock (recovery clock) ostatniego eventu
• Czas trwania: wyliczony automatycznie
• Dotknięte systemy: nazwy hostów z host.name i grup hostów z hostgroup.name
• Symptomy: lista triggerów, które zadziałały, z ich severity
• Prawdopodobna przyczyna: hipoteza AI na podstawie analizy timeline'u
• Działania naprawcze: jeśli administrator wpisał komentarz w Zabbix (pole event.acknowledges) albo adnotację w Grafanie

Szkic trafia do wybranego miejsca: Confluence, dokument w Notion, ticket w GLPI, wiadomość na Slacku do kanału incydentów. Ktoś przegląda, dopisuje kontekst, zatwierdza. Czas poświęcony na rejestr spada z kilkudziesięciu minut do kilku minut weryfikacji.

Od czego zaczynamy integrację?

Pierwsze kroki są powtarzalne niezależnie od środowiska. W Zabbix tworzymy użytkownika read-only i sprawdzamy, czy API na /api_jsonrpc.php jest dostępne. W Grafanie zakładamy Service Account z rolą Viewer i generujemy token. Potem definiujemy zakres: które grupy hostów AI ma śledzić i jaki minimalny severity ją interesuje. Zwykle Average i wyżej. Poniżej to szum, który bardziej przeszkadza niż pomaga.

Warto zacząć od streszczenia nocnego. Przynosi efekt od pierwszego dnia i nie wymaga kalibracji. Grupowanie przyczyn i wykrywanie trendów konfiguruje się w drugim kroku, gdy AI ma już kontekst, jak wygląda normalne środowisko tej firmy.

Jeśli chcesz zobaczyć, jak to wyglądałoby w Twoim monitoringu, umów się na bezpłatny audyt. Sprawdzimy, co masz w Zabbix, Grafanie albo Prometheusie i powiemy wprost, co AI może z tych danych wyciągnąć. Możesz też zajrzeć do realnych wdrożeń, żeby zobaczyć, jak to wyszło u innych firm.