Alarmer i Zabbix

Det er mange av oss som har definert alarmer (Triggers) i Zabbix i de siste måneder. I dette dokumentet skal vi gi noen tips som kan hjelpe oss å definere bedre alarmer som også kan brukes og forstås av andre enn de som definerer dem.

Alvorlighetsgrad

I Zabbix kan man definere alarmer med 5 forskjellige alvorlighetsgrader. Disse alvorlighetsgrader kan brukes for å filtrere bort alarmer man ikke er interesert i, eller si noe om hva slags konsekvenser alarmen har i vår hverdag.

Vi har definert de 5 alvorlighetsgrader slik:

	Severity	Name
1	Disaster	Nedetid av en sentral tjeneste Alvorlige feil med store konsekvenser for UiO eller mange brukere. Disse alarmer burde kun brukes i spesielle tilfeller.
2	High	Disse alarmer er problemer som noen burde fikse eller se på asap. Disse alarmer kan forårsake av en tjeneste får redussert kapasitet uten å bli utilgjengelig. De kan ogå brukes på viktig feil som må fikses uten at konsekvensene er så dramatisk som i "Disaster" graden
4	Average	Disse alarmer er problemer som noen burde fikse eller se på ved anledning. Disse problemene burde ikke forårsake redussert kapasitet eller nedetid av en tjeneste. Hvis de ikke blir fikset kan de forårsaker større problemer på et senere tidspunkt
7	Warning	Disse alarmer er egentlig ikke problemer som må fikses. De gir oss informasjon om ting som skjer som potensielt kan bli et problem på et senere tidspunkt.
8	Information	Disse alarmer er egentlig ikke problemer som må fikses. De gir oss informasjon om endringer som skjer i våre systemer som kan være fint å registrere eller få beskjed om.

Tenk nøye over hvor viktig en alarm er og konsekvenser av alarmen, bruk riktig alvorlighetsgrad når dere definerer en alarm. Dette kommer til å gjøre jobben vår enklere i det lange løp.

Alarm beskrivelse

Beskjeden vi får når en alarm genereres er veldig viktig. Bruk litt tid på å lage en beskjed som er kort, konsis men som gir nok informasjon til å forstå hva slags alarm har blitt generert.

Et god eksemplet på beskjed fra en alarm kunne være:

"The service SSHD is not running on this host"

I motsetning til e.g.:

"Problem with SSHD"

eller:

"SSHD problem"

Første beskjed gir oss informasjon om at vi har problemer med SSHD, hva slags problem vi snakker om. Samtidig er det kort og konsist.

Husk at alarmen skal sannsynligvis vises eller leses av andre og at i noen tilfeller er det andre enn deg som må ta en beslutning om hvor alvorlig en alarm er og om noe skal gjøres med det.

Alarm avhengigheter

Når man definerer en ny trigger/alarm kan man også definere andre triggere man er avhengig av. Denne funksjonaliteten brukes for å unngå å få unødvendige alarmer og kun få alarmer som er rot årsaken til at ting har feilet. E.g. vi har en avhengighet i basis overvåking mellom alle triggere/alarmer og en trigger som genereres når en maskin er nede. Hvis en maskin er nede vises kun denne alarmen og ikke andre, og dette er mulig på grunn av anhengighetsfunksjonalitet.

Prøv også å ikke gjøre det for komplisert for å unngå at man mister oversikten og genererer loops problemer

Alarm kommentar

Man kan definere en kommentar (Description) når man definerer en trigger (alarm). Bruk dette feltet for å forklare hva slags feil man har definert, mulige årsaker eller løsninger. Innholdet i dette feltet kan hentes fra flere steder.

Alarm acknowledgement

Vi anbefaler at man bekrefter (acknowledge) en alarm hvis grunnen til at alarmen har blitt generert ikke vil forsvinne med en gang og vi jobber med saken for å fikse problemet. Dette kan gjøre det enklere for andre å filtrere bort alarmer som har blitt bekreftet og gir informasjon om at noen jobber med saken.

Dette kan gjøres bl.a. via https://monitor.uio.no/ ved å klikke på "Ack (No)" lenken fra en alarm i dashboard oversikten.