Jag hade övervakning. Jag hade en inventarieförteckning. Problemet var att de inte visste om varandra, och att bara den ena av dem hade rätt.
En sak att veta innan vi går vidare: jag konfigurerar knappt någonting för hand längre. Arbetet i den här texten utfördes av AI-agenter med mig som beställare — jag beskriver vad som ska gälla, granskar vad som faktiskt hände och fattar besluten. Det är inte en parentes i berättelsen. Det är det som gör att fällan längre ner blir farlig.
Utgångsläget: grått och rött
Övervakning växer sällan fram enligt en plan. En server läggs till när den sätts i drift, en annan i all hast under en incident, och en tredje glöms bort helt. Efter ett par år ser översikten ut ungefär så här: hälften av maskinerna är gröna, resten är grå eller röda, och ingen minns om det betyder att de är trasiga eller bara felkonfigurerade.
Orsakerna visade sig vara pinsamt banala. En del hostar saknade agent-interface helt. Andra hade interface men ingen mall kopplad, alltså inga mätvärden att samla in. Namnsättningen var tre olika konventioner i lager på varandra, beroende på vilket år hosten lades in.
Först: en kväll av snabba fixar
Det gick att rätta till. Jag bad om det, och en agent gjorde jobbet — skapade interfaces, kopplade mallar, arbetade sig igenom listan via API:et. Det tog minuter, inte en kväll. Allt lyste grönt.
Dagen efter var flera hostar grå igen.
Här ligger något värt att stanna vid. En agent som får i uppgift att göra en host grön väljer den kortaste vägen dit, och den kortaste vägen är nästan alltid att ändra direkt i systemet som visar färgen. Den gör det snabbt, korrekt och i fel ände. En människa som klickar sig igenom samma sak hinner åtminstone bli less och undra om det finns ett bättre sätt. Agenten blir aldrig less.
Beslutet: en enda källa till sanning
Slutsatsen var inte att sluta använda agenter. Den var att sluta lita på att den som utför arbetet — människa eller modell — ska välja rätt ställe att göra det på. Det måste avgöras av hur systemet är byggt.
Rollfördelningen blev:
- NetBox är facit. Här står vad som finns, vad det heter, vilken adress det har och vad det är för sorts sak.
- Zabbix är väktaren. Här mäts och larmas det — men Zabbix bestämmer inte själv vad som ska övervakas.
- Synken går åt ett håll. NetBox till Zabbix. Aldrig tillbaka.
Kopplingen sköts av nbxsync, ett NetBox-plugin som skapar och uppdaterar hostar i Zabbix utifrån innehållet i NetBox. Ett bakgrundsjobb kör synken var sextionde sekund.
Fällan: enkelriktat betyder verkligen enkelriktat
Om synken är auktoritativ åt ena hållet är allt som inte finns i facit per definition fel — och blir bortstädat. De handgjorda mall-tilldelningarna och interfacen fanns bara i Zabbix. Nästa synkcykel såg hostar vars konfiguration avvek från facit och rättade dem. Var sextionde sekund, tålmodigt, tills vi förstod vad som pågick.
Lösningen är inte att stänga av synken. Den är att modellera mall-tilldelningar och host-interfaces i NetBox — som egna objekt kopplade till respektive maskin — och sedan låta synken göra jobbet. Ett interface pekar dessutom på en riktig IP-adress i NetBox IPAM, inte på en textsträng.
Det kändes omständligt i stunden. Det är också hela poängen: efteråt går det inte längre att lägga till en maskin i övervakningen utan att den först existerar i inventariet. Genvägen är stängd — inte bevakad, stängd.
Tre mindre fällor på vägen
”Invalid parameter /1/groups: cannot be empty” — synken vägrade skapa hostar. Felet kom från Zabbix API men orsaken låg i NetBox: host-grupperna hade namn i gränssnittet men ett tomt värdefält under ytan. Pluginet renderar det fältet som en mall, tom sträng in ger tom sträng ut, och Zabbix avvisar hela anropet. Fyll i värdefältet på varje hostgrupp.
host.update ersätter, den lägger inte till. Skickar man in en mall med host.update försvinner de mallar som redan satt på hosten. Vill man komplettera är host.massadd rätt anrop. Den här kostade en runda av ”men den där lade vi ju precis på”.
Autentiseringen mot API:et bytte form i Zabbix 7. Token ska numera skickas som Authorization: Bearer-header, inte som ett auth-fält i anropskroppen. Äldre exempel på nätet gör det senare, och felmeddelandet man får är inte till någon hjälp. Lägg till att en API-token kan sluta gälla utan att något skriker om det — synken bara tystnar, och en tyst synk ser precis ut som en synk utan arbete att göra.
Vad som ändras när agenter gör jobbet
Jag har inte skrivit den här miljöns konfiguration för hand på länge. Jag beskriver vad som ska gälla, agenter utför, och jag granskar resultatet. Det fungerar förvånansvärt bra — och det förändrar vilka fel man behöver skydda sig mot.
Hastighet förstorar avdrift. Den som ändrar tjugo saker i minuten hinner skapa mer oordning innan lunch än vad en människa gör på en vecka. Ett facit är inte mindre viktigt när arbetet automatiseras — det är förutsättningen för att automatiseringen ska vara ofarlig.
Disciplin fungerar inte som skydd. Man kan komma överens med sig själv om att alltid gå via inventariet. Man kan inte komma överens om det med en modell som får uppgiften ”se till att den här hosten övervakas” nästa gång, i en annan session, utan minnet av den här kvällen. Det som håller är att den felaktiga vägen inte leder till ett bestående resultat — och det är precis vad en enkelriktad synk gör.
Grönt är inte ett bevis. En agent som får i uppdrag att göra något grönt kommer att lyckas göra det grönt. Frågan är om färgen betyder att det fungerar eller bara att någon precis rört vid det. Därför måste verifieringen vara mekanisk och tidsfördröjd — se nästa avsnitt.
Resten av ordningen
Två saker till gjordes samtidigt, och de hör ihop med samma tanke.
Alla hostnamn standardiserades till ett enda format med tillhörande DNS-poster. Det låter kosmetiskt. Det är det inte: när namnet i inventariet, namnet i övervakningen och namnet i DNS är samma sträng kan de matchas maskinellt, och då blir frågan ”är allt övervakat?” möjlig att svara på med en jämförelse i stället för med en känsla.
Och agenterna — den här gången i betydelsen övervakningsagenter — rullades ut med Ansible på både Linux- och Windows-sidan. Samma princip en gång till: det som utförs ad hoc kommer att se olika ut på olika maskiner, och skillnaderna upptäcks alltid vid sämsta tänkbara tillfälle.
Så vet du att det funkar
Det räcker inte att titta på en grön ikon direkt efter en ändring. Testet är att göra ändringen och sedan vänta ut minst en synkcykel — i det här fallet en dryg minut — och titta igen. Står konfigurationen kvar har den sitt ursprung i facit. Har den försvunnit gjordes den i fel ände.
Ett andra test: lägg in en ny maskin i inventariet med rätt grupp, mall och interface, och rör inte övervakningen alls. Dyker den upp av sig själv och börjar samla in data, då fungerar kedjan. Måste någon hjälpa till på slutet är något fortfarande manuellt.
Titta också i synkjobbets logg, inte bara i webbgränssnittet. Där syns skillnaden mellan ”synken körde och hade inget att göra” och ”synken körde aldrig”.
Vad jag tar med mig
Övervakning som konfigureras ad hoc glider isär. Det tar ett par år med människor vid tangentbordet och betydligt kortare tid med agenter, men det händer alltid, och man märker det först när något går sönder på en maskin som ingen kom ihåg att lägga in.
Den obekväma delen av att införa ett facit är inte tekniken. Det är att sluta lösa saker där det går snabbast. Varje gång något rättades direkt i övervakningen blev det rätt i tjugo sekunder och fel en minut senare — och det var systemet som hade rätt, inte vi.
Vinsten kommer när frågan ”övervakas allt vi äger?” går från att vara en åsikt till att vara en jämförelse mellan två listor. Det är hela skillnaden mellan att ha övervakning och att kunna lita på den — och det är också vad som gör att jag vågar låta en modell utföra arbetet.