SNMP-overvågning i Odoo 19: Grænseværdi overskredet, supportsag oprettet
Servere, switche, UPS-anlæg, temperaturfølere i serverrummet: Næsten alt, der er tilsluttet et netværk, taler SNMP og kan oplyse om sin tilstand. Spørgsmålet er blot, hvem der lytter – og hvad der sker, når en værdi kommer ud af kontrol.
For den infrastruktur, vi administrerer for vores kunder, har vi nu samlet hele forløbet ét sted: Vores Odoo 19 forespørger enhederne, sammenligner værdierne med grænseværdier og opretter en sag i helpdesken, når en grænse nås – hos den kunde, enheden tilhører. Det hele foregår i det samme system, hvor kunde, enhed og supportsag allerede er knyttet sammen, uden et separat overvågningssystem, der sender e-mails til helpdesken.
Vi har udviklet modulet til vores egen drift. Det er ikke udgivet til communityet som vores moduler til kontoudtog eller e-fakturaer, men er en del af vores interne serviceplatform – ligesom sporingen, som vi senest har fortalt om.
Fra måleværdi til supportsag
Forløbet er bevidst holdt enkelt:
- En enhed oprettes med adresse og adgangsoplysninger (SNMP v1, v2c eller v3 med godkendelse og kryptering). Når den gemmes, henter Odoo systembeskrivelse, systemnavn og oppetid – den mest pålidelige bekræftelse på, at adressen og adgangsoplysningerne er korrekte.
- På enheden defineres datapunkter: en OID, en måleenhed og en kundetilknytning.
- En planlagt kørsel forespørger alle aktive datapunkter. Der oprettes én forbindelse pr. enhed, ikke pr. datapunkt – med tyve OID'er på en switch er det forskellen på én og tyve sessioner.
- Hvert datapunkt kan overvåge grænseværdier: en øvre grænse, en nedre grænse eller begge dele.
- Hvis en grænse overskrides, oprettes der en supportsag.
Én sag pr. hændelse, ikke pr. måling
Det vigtigste punkt i alarmlogikken: Kun tilstandsskiftet tæller. Den, der opretter et ticket ved hver måling, har efter en nat med en sensor, der hænger eller preller, tre hundrede tickets – det er ikke alarmering, det er tilsløring.
Modulet husker derfor pr. datapunkt, om det befinder sig i tilstanden »Normal« eller »Alarm«. Ved den første overskridelse af grænsen skifter tilstanden, en besked havner i enhedens chatter, og et ticket åbnes – med den berørte kunde som partner, med datapunkt, enhed, målt værdi og overskredet grænse i teksten. Så længe værdien forbliver uden for grænsen, sker der intet yderligere: Ticket er åbent, vores teknikere ved besked.
Når værdien vender tilbage til normalområdet, skriver modulet en besked om, at alarmen er ophørt, i den samme supportsag og fjerner tilknytningen. Det er fortsat et menneske, der afgør, om sagen skal lukkes – at en værdi kortvarigt falder under grænsen, betyder ikke nødvendigvis, at årsagen er afhjulpet.
Grænseværdier kontrolleres ved hver måling, uanset om værdien gemmes. En konstant for høj værdi er stadig en alarm. Og en alarm må aldrig gå tabt, fordi en supportsag ikke kan oprettes – mislykkes oprettelsen, bevares loggen og beskeden på enheden alligevel.
Gem kun det, der ændrer sig
Et datapunkt, der forespørges hvert femte minut, leverer 105.000 værdier om året. Med hundrede datapunkter bliver det til over ti millioner rækker – for værdier, der som regel slet ikke har ændret sig.
Derfor gemmes kun værdier, der afviger fra den senest gemte værdi med mere end en indstillet tærskel – for hvert datapunkt enten som en absolut forskel (f.eks. 0,5 °C), som en procentvis afvigelse eller ved enhver ændring. Den aktuelle værdi og tidspunktet for den seneste forespørgsel fremgår stadig altid af datapunktet. Det er kun historikken, der gemmes færre værdier i.
Det kan også indstilles, hvor værdierne gemmes: i Odoo-databasen, i en MongoDB eller som CSV-filer i Odoos fillager. På den måde holder vi måleværdierne ude af ERP-databasen – samme princip som for sporingssystemets positionsdata. Historikken kan i alle tilfælde vises som et diagram. Når data samles pr. time, bruges gennemsnittet, ikke summen.
Udnyttelsesgrad i procent frem for bytes
Nogle størrelser findes ikke direkte på enheden. En partitions udnyttelsesgrad skal beregnes ud fra den brugte plads og den samlede størrelse. Temperaturfølere leverer ofte skalerede heltal – 235 for 23,5 grader.
Et datapunkt kan derfor overtage værdien, som den rapporteres, gange den med en faktor eller beregne den som en procentdel af en anden OID. Det er afgørende for grænseværdier: En grænse på 90 % gælder uanset diskstørrelse. En grænse i gigabyte skulle løbende justeres for hvert drev.
Ingen behøver at kunne OID'er udenad
På Windows- og Linux-servere er HOST-RESOURCES-MIB standardiseret: Drev og arbejdshukommelse findes på kendte placeringer. Enhedsregistreringen læser tabellen, omregner udnyttelsesgraden til procent og opretter datapunkterne med alarmgrænse med ét klik.
Til alt andet er der en SNMP-browser, som gennemgår OID-træet og viser hver funden OID med dens aktuelle værdi — og, hvis den findes i kataloget, med navn, beskrivelse og enhed fra producentens importerede MIB. Du skal blot sætte flueben.
Hvad vores kunder får ud af det
Enheder og datapunkter er knyttet til kunder. I kundeportalen finder du under Mine SNMP-værdier dine enheders aktuelle måleværdier og historikken for de seneste 24 timer, 7 dage, 30 dage eller 12 måneder som diagram — de samme værdier, som vi ser. Du kan kun se det, der er knyttet til din virksomhed.
Og hvis en grænseværdi overskrides, behøver du ikke gøre noget: Supportsagen er allerede hos os med enhed, værdi og tidspunkt, før du opdager det.
Hvad modulet bevidst ikke er
Det erstatter ikke et fuldt overvågningssystem med tilgængelighedskontrol, eskaleringskæder og afhængighedstræer. Det modtager ikke SNMP-traps, men forespørger aktivt. Og det lukker ingen supportsager automatisk — beskeden om, at alt igen er normalt, er en meddelelse, ikke en statusændring.
Det handler om én bestemt vej: fra en måleværdi, der overskrider grænsen, til den tekniker, der tager hånd om det. Den vej er nu så kort, som den kan blive.
Kontakt os, hvis du vil have dine servere, netværksenheder eller sensorer med i denne overvågning.