Övervakningsagenten på en av servrarna vägrade starta. Felmeddelandet var ovanligt hjälpsamt:
ERROR: Cannot read configuration: cannot include
"/etc/zabbix/zabbix_agent2.d/<fil>.conf": permission deniedTvå fel, egentligen. Det första tog två minuter att lösa. Det andra tog längre tid, för det gav ett symptom som pekade åt fel håll.
Fel ett: rättigheter, inget annat
Konfigurationsfilen hade läget 600 — läsbar enbart för root. Agenten körs som en egen, mindre privilegierad användare. Den kunde alltså se att filen fanns, men inte läsa den, och vägrade då starta överhuvudtaget i stället för att hoppa över raden.
Fixen är en rad:
chmod 644 /etc/zabbix/zabbix_agent2.d/<fil>.conf
systemctl restart zabbix-agent2Det intressanta är inte fixen utan hur filen hamnade där. Den lades dit av en automatiserad utrullning som körde som root, och den ärvde rättigheterna från den som skrev den. Ingen människa valde 600. Det bara blev så.
Det här är den vanligaste klassen av fel jag ser numera, när jag inte längre skriver konfigurationen för hand utan låter agenter göra jobbet: innehållet i filen är korrekt, placeringen är korrekt, syntaxen är korrekt — och rättigheterna är fel, för de var aldrig en del av uppgiften. Den som skriver en fil som root tänker sällan på vem som ska läsa den sedan. Vill man undvika det ska önskad ägare och läge stå i uppgiften, inte antas.
En detalj värd att notera: agenten vägrade starta snarare än att starta med en varning. Det är rätt beteende. En övervakningsagent som tyst hoppar över halva sin konfiguration är farligare än en som är nere, eftersom en nere agent larmar och en halvkonfigurerad ser frisk ut.
Fel två: ”Timeout occurred while gathering data”
Med agenten igång började mätvärdena komma in — utom för de kontroller som var själva anledningen till att filen fanns. De rapporterade timeout.
Orsaken var enkel: kontrollerna kör ett skript som tar två till tre sekunder, och standardvärdet för timeout var tre sekunder på agentsidan. Marginalen var alltså noll, och utfallet berodde på hur upptagen maskinen råkade vara.
Här ligger fällan, och den kostade mest tid: timeout har två ändar. Både agenten och servern har ett eget tak, och servern ger upp oberoende av vad agenten håller på med. Höjer man bara på den ena sidan får man exakt samma felmeddelande som innan, vilket lätt tolkas som att höjningen inte hjälpte. Båda måste upp.
Ett rimligt värde är rejält tilltaget snarare än precis över mätningen. Ett skript som tar tre sekunder på en ledig maskin tar gärna tolv när disken har fullt upp med något annat, och det är just då man vill ha mätvärdet.
Så vet du att det funkar
Att tjänsten är igång betyder ingenting i sig. systemctl status säger ”active” även när agenten samlar in noll av de kontroller den installerades för.
Kontrollera i stället tre saker, i den här ordningen:
- Att tjänsten är kvar efter en omstart av maskinen — inte bara efter en omstart av tjänsten.
- Att varje enskilt mätvärde faktiskt har ett värde, med en tidsstämpel som är färsk. Ett item som aldrig fyllts i ser i många vyer ut precis som ett item som är i sin ordning.
- Att det håller under belastning. Kör kontrollen medan maskinen har något annat för sig och se om den fortfarande hinner klart.
Vad jag tar med mig
Läs felmeddelandet bokstavligt. ”Permission denied” på en inkluderad fil betyder rättigheter. Inte brandvägg, inte SELinux, inte en trasig installation. Den enklaste förklaringen var den rätta, men jag lade ändå några minuter på att misstänka finare saker först.
Automatisering ärver rättigheter, den väljer dem inte. När konfiguration skrivs av något som kör som root blir resultatet läsbart för root. Ska någon annan läsa filen måste det stå i uppgiften.
Övervakning som inte övervakas är en åsikt. Två fel i rad gjorde att en uppsättning säkerhetskontroller såg ut att vara på plats utan att samla in ett enda värde. Ingenting larmade om det, för det som inte mäts kan inte larma om sin egen frånvaro. Det är därför sista steget alltid måste vara att titta efter data — inte efter grönt.