AI-agenten der ikke bare læser dine Zabbix alarmer – men undersøger årsagen

Et af temaerne på Zabbix Summit var – som man kunne forvente i 2026 – AI. Men et indslag, der fangede mig, var ikke om at få LLM’en til at læse alarmer. Det var ideen om at give AI’en adgang til selve systemerne, så men bedre og hurtigere kan finde årsagen til problemet.

Sådan virker det i grove træk: Zabbix fanger at noget er galt. I stedet for at vække en halvsøvnig sysadmin kl. 3  on natten, som skal starte med at forsøge at finde problemet, kan man bruge en AI-agent til at lave en undersøgelse af problemet:

1. Agenten holder øje med Zabbix – hvad er det egentlig, der er advarslen om? Hvilke hosts, hvilke items, og hvordan er historikken op til?
   Er der sammenhæng mellem andre alarmer, kunne det være diskplads på en host, høj load på en database, et netværk der har problemer samtidig.
2. Agenten logger på serveren – og ser, hvad der faktisk sker. Diskforbrug pr. mappe, processer der spiser hukommelsen, logfilerne for de sidste timer, hvad der er blev ændret siden i går osv.
3. Agenten forklarer – i steder for alarmen i Zabbix som siger “Disk 91% fuld”, kommer den med mere konkrete informationer om problemer “mappe /var/log fylder 400 GB fordi en applikation logger i debug-mode siden sidste deploy – her er loglinjerne, og her er hvad der skal slettes/rettes”.

Det sidste punkt er det vigtige. Det er her forskellen på overvågning og hurtig forståelse af problemet er.

Zabbix Summit indslagets konkrete indhold

Det konkrete indslag, jeg sad og blev fanget af, var “AIOps Automation from Zabbix Events” med Ilkka Tengvall, som er Solution Architect, Red Hat. Pointen i indslaget var, at man kan kæde Zabbix-events sammen med Ansible Automation Platform, så en hændelse i Zabbix ikke bare ender i en ticket eller en Slack-besked, men faktisk udløser en automatiseret, defineret respons.

Det, der gjorde indtryk på mig, var ikke automatiseringen i sig selv – actions har vi haft i årevis i Zabbix. Det var at Zabbix-eventet bliver et input til en agent, der kan gennemføre en undersøgelse, samle kontekst og præsentere en anbefaling – ikke bare en regel, der blindt kører et playbook af.
AIOps er helt sikkert en naturlig næste skridt, for at løse problemer hurtigere,

Sikkerheden – ingen “AI med root-adgang, tak”

Der er helt klart noget at tænke på her inden man bare slipper agenter løs på serverene.
En agent kan potentielt, lige som en bruger, have rettigheder til at ændre noget eller genstarte serveices osv. så inden man slipper den løs, så skal du tænke på hvad der kan ske og på en eller anden måde sikre sig at agenten ikke kan lave for meget ballade.

Hvis jeg kan lave så agenten kun har “read” adgang til systemerne og den så kan finde frem til en løsning vil det være fedt. Så kan den komme med ændringer til Ansible, som jeg nemt kan gennemgå og rulle ændringer ud manuelt. Det vil så kunne give en sikkerhed for at jeg ved hvad der sker og jeg har et audit spor, så jeg altid ved hvad der er lavet på serverene.

Min holdning

Jeg er både vildt fasineret at hvad vi kan bruge agenter til, men samtidig er jeg skeptisk for at agenten ikke pludselig laver ravage. Så lige nu vil jeg, ind til videre, kun slippe agenter løs direkte på demo servere for at teste det.

Til produktion vil jeg ind til videre hellere lade agenten få read adgang til alle de logs jeg har i Elasticsearch, så den kan hjælpe mig med at finde problemt hurtigt og komme med ændringsforlag til Ansible, som jeg så kan rulle ud.

Jeg vil råde alle til det samme: Start forsigtigt, read-only først, og lad agenten bevise sin værdi som diagnostiker, før man overhovedet overvejer at give den fuld adgang.