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.

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 |
|
2 | High |
|
4 | Average |
|
7 | Warning |
|
8 | Information |
|
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.
Logg inn for å kommentere
Ikke UiO- eller Feide-bruker?
Opprett en WebID-bruker for å kommentere