Odoo 19 Community: SNMP-overvåking med automatisk ticketopprettelse – vår åpen kildekode-modul

SNMP-overvåking i Odoo 19: Grenseverdi overskredet, ticket åpnet

Servere, svitsjer, UPS-anlegg, temperaturfølere i serverrommet: Nesten alt som henger i et nettverk, snakker SNMP og kan gi opplysninger om tilstanden sin. Spørsmålet er bare hvem som lytter – og hva som skjer når en verdi går ut av kontroll.

For infrastrukturen vi drifter for kundene våre, har vi nå samlet denne kjeden ett sted: Vår Odoo 19 spør enhetene, sammenligner verdiene med grenseverdier, og når en grense nås, åpner den en ticket i helpdesken – hos kunden som eier enheten. Ikke et separat overvåkingssystem som skriver til helpdesken via e-post, men det samme systemet der kunde, enhet og ticket uansett henger sammen.

Modulen har vi utviklet for egen drift. Den er ikke en fellesskapspublisering som modulene våre for kontoutskrifter eller e-fakturaer, men en del av vår interne driftsplattform – slik som sporingen vi sist skrev om.

Fra målverdi til ticket

Forløpet er bevisst holdt enkelt:

1. En enhet opprettes med adresse og påloggingsopplysninger (SNMP v1, v2c eller v3 med autentisering og kryptering). Ved lagring henter Odoo systembeskrivelse, systemnavn og uptime – den ærligste bekreftelsen på at adresse og påloggingsopplysninger stemmer.
2. På enheten defineres datapunkter: en OID, en enhet, en kundetilordning.
3. En tidsplan spør alle aktive datapunkter. Per enhet kobles det til én gang, ikke per datapunkt – ved tjue OID-er på en svitsj er det forskjellen mellom én og tjue sesjoner.
4. Hvert datapunkt kan overvåke grenseverdier: en øvre grense, en nedre grense eller begge.
5. Hvis en grense overskrides, opprettes en helpdesk-ticket.

Én ticket per hendelse, ikke per måling

Det viktigste punktet i alarmlogikken: Bare tilstandsendringen teller. Den som oppretter en ticket for hver måling, har etter en natt med en fastklemt eller prellende sensor trehundre tickets – det er ikke varsling, det er tåkelegging.

Modulen husker derfor per datapunkt om det er i tilstanden «Normal» eller «Alarm». Ved første overskridelse av grensen skifter tilstanden, en melding havner i enhetens chatter, og en ticket åpnes – med den berørte kunden som partner, med datapunkt, enhet, målt verdi og overskredet grense i teksten. Så lenge verdien blir utenfor grensen, skjer ikke noe mer: Ticketen er åpen, teknikerne våre vet beskjed.

Når verdien går tilbake til normalområdet, skriver modulen en avblåsning i den samme ticketen og løser opp koblingen. Om ticketen deretter lukkes, avgjør fortsatt et menneske – en verdi som kort faller under grensen, betyr ennå ikke at årsaken er rettet.

Grenseverdier kontrolleres ved hver måling, uavhengig av om verdien lagres. En verdi som konstant er for høy, forblir en alarm. Og en alarm må aldri svikte fordi en ticket ikke kan opprettes – hvis opprettelsen mislykkes, blir protokoll og melding på enheten likevel stående.

Lagre bare det som endrer seg

Et datapunkt som spørres hvert femte minutt, gir 105 000 verdier i året. Ved hundre datapunkter er det over ti millioner linjer – for verdier som oftest ikke har endret seg i det hele tatt.

Det lagres derfor bare det som avviker fra den sist lagrede verdien med mer enn en innstilt terskel – per datapunkt som absolutt differanse (for eksempel 0,5 °C), som prosentvis avvik eller ved hver endring. Den aktuelle verdien og tidspunktet for siste spørring står likevel alltid på datapunktet; det er bare historikken som tynnes ut.

Hvor verdiene skrives, kan også stilles inn: til Odoo-databasen, til en MongoDB eller som CSV-filer i Odoo-filestore. Vi holder dermed målverdiene utenfor ERP-databasen – det samme grunnprinsippet som for posisjonsdataene i sporingen. Historikken kan i alle tilfeller vises som diagram, ved timevis fortetting som gjennomsnitt, ikke som sum.

Fyllingsgrad i prosent i stedet for i byte

Noen størrelser finnes ikke som sådan i enheten. Fyllingsgraden til en partisjon må beregnes ut fra belagt lagring og totalstørrelse; temperatursensorer leverer ofte skalerte heltall – 235 for 23,5 grader.

Et datapunkt kan derfor overta verdien som meldt, multiplisere den med en faktor eller beregne den som prosentandel av en andre OID. For grenseverdier er dette avgjørende: En grense på 90 % gjelder for enhver diskstørrelse. En grense i gigabyte måtte vedlikeholdes per stasjon.

Ingen trenger å kunne OID-er utenat

For Windows- og Linux-servere er HOST-RESOURCES-MIB standardisert: Stasjoner og arbeidsminne står på kjent sted. En enhetsgjenkjenning leser tabellen, regner om fyllingsgrader til prosent og oppretter datapunktene sammen med alarmgrense med ett klikk.

For alt annet finnes en SNMP-nettleser som går gjennom OID-treet og viser hver funnet OID med dens aktuelle verdi – og, hvis kjent i katalogen, med navn, beskrivelse og enhet fra den importerte produsent-MIB-en. Det holder å krysse av.

Hva kundene våre har igjen for det

Enheter og datapunkter er tilordnet kunder. I kundeportalen finner du under Mine SNMP-verdier de aktuelle målverdiene til enhetene dine og historikken for de siste 24 timene, 7 dagene, 30 dagene eller 12 månedene som diagram – de samme verdiene som vi også ser. Synlig er utelukkende det som er tilordnet din virksomhet.

Og når en grenseverdi overskrides, trenger du ikke gjøre noe: Ticketen er allerede hos oss, med enhet, verdi og klokkeslett, før du merker det.

Hva modulen bevisst ikke er

Den er ikke en erstatning for en fullstendig overvåking med tilgjengelighetskontroller, eskaleringskjeder og avhengighetstrær. Den tar ikke imot SNMP-traps, men spør aktivt. Og den lukker ingen ticket automatisk – avblåsningen er en melding, ikke en statusendring.

Det handler om nøyaktig én strekning: fra målverdien via grensen til teknikeren som tar seg av saken. Denne strekningen er nå så kort som den kan bli.

Hvis du vil ta serverne, nettverksenhetene eller sensorene dine med i denne overvåkingen, ta kontakt med oss.