SNMP-overvågning i Odoo 19: Grænseværdi overskredet, ticket oprettet
Servere, switche, UPS-anlæg, temperaturfølere i serverrummet: Næsten alt, hvad der hænger på et netværk, taler SNMP og kan give besked om sin tilstand. Spørgsmålet er blot, hvem der lytter – og hvad der sker, når en værdi løber ud af kurs.
Til den infrastruktur, vi betjener for vores kunder, har vi nu lagt denne kæde ét sted: Vores Odoo 19 forespørger enhederne, sammenligner værdierne med grænseværdier, og når en grænse nås, åbner det et ticket i helpdesken – hos den kunde, som enheden tilhører. Intet separat overvågningssystem, der skriver til helpdesken via e-mail, men det samme system, hvor kunde, enhed og ticket under alle omstændigheder hænger sammen.
Modulet har vi udviklet til vores egen drift. Det er ikke en community-udgivelse som vores moduler til kontoudtog eller e-fakturaer, men en del af vores interne betjeningsplatform – ligesom sporingen, som vi sidst har berettet om.
Fra måleværdi til ticket
Forløbet er bevidst holdt enkelt:
- En enhed oprettes med adresse og adgangsdata (SNMP v1, v2c eller v3 med autentificering og kryptering). Ved gemning henter Odoo systembeskrivelse, systemnavn og uptime – den ærligste bekræftelse på, at adresse og adgangsdata er korrekte.
- På enheden defineres datapunkter: en OID, en enhed, en kundetilknytning.
- En tidsplan forespørger alle aktive datapunkter. Pr. enhed oprettes forbindelse én gang, ikke pr. datapunkt – ved 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.
- Overskrides en grænse, oprettes et helpdesk-ticket.
Ét ticket 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.
Vender værdien tilbage til normalområdet, skriver modulet en afblæsning i det samme ticket og løsner forbindelsen. Om ticket derefter lukkes, afgør fortsat et menneske – en værdi, der kortvarigt falder under grænsen, betyder endnu ikke, at årsagen er afhjulpet.
Grænseværdier kontrolleres ved hver måling, uafhængigt af om værdien gemmes. En konstant for høj værdi forbliver en alarm. Og en alarm må aldrig strande på, at et ticket ikke kan oprettes – mislykkes oprettelsen, består protokol og besked på enheden alligevel.
Gem kun det, der ændrer sig
Et datapunkt, der forespørges hvert femte minut, leverer 105.000 værdier om året. Ved hundrede datapunkter er det over ti millioner rækker – for værdier, som for det meste slet ikke har ændret sig.
Der gemmes derfor kun det, der adskiller sig fra den sidst gemte værdi med mere end en indstillet tærskel – pr. datapunkt som absolut forskel (f.eks. 0,5 °C), som procentuel afvigelse eller ved hver ændring. Den aktuelle værdi og tidspunktet for den sidste forespørgsel står alligevel altid på datapunktet; kun forløbet tyndes ud.
Hvortil værdierne skrives, kan ligeledes indstilles: i Odoo-databasen, i en MongoDB eller som CSV-filer i Odoo-filestore. Vi holder dermed måleværdierne ude af ERP-databasen – det samme grundprincip som ved sporingens positionsdata. Forløbet kan i alle tilfælde vises som diagram, ved timevis fortætning som gennemsnit, ikke som sum.
Fyldningsgrad i procent i stedet for i bytes
Nogle størrelser står ikke som sådan i enheden. En partitions fyldningsgrad skal beregnes ud fra brugt lager og samlet størrelse; temperatursensorer leverer ofte skalerede heltal – 235 for 23,5 grader.
Et datapunkt kan derfor overtage værdien som meldt, gange den med en faktor eller beregne den som procentsats af en anden OID. For grænseværdier er det afgørende: En grænse på 90 % gælder for enhver disks størrelse. En grænse i gigabyte måtte vedligeholdes for hvert drev.
Ingen behøver at kende OID'er udenad
Ved Windows- og Linux-servere er HOST-RESOURCES-MIB standardiseret: Drev og arbejdshukommelse står på et kendt sted. En enhedsgenkendelse læser tabellen, omregner fyldningsgrader til procent og opretter datapunkterne inklusive alarmgrænse med ét klik.
Til alt andet findes en SNMP-browser, der gennemløber OID-træet og viser hver fundet OID med dens aktuelle værdi – og, hvis den er kendt i kataloget, med navn, beskrivelse og enhed fra den importerede producent-MIB. Det er nok at sætte kryds.
Hvad vores kunder får ud af det
Enheder og datapunkter er tilknyttet kunder. I kundeportalen finder De under Mine SNMP-værdier de aktuelle måleværdier for Deres enheder og forløbet de seneste 24 timer, 7 dage, 30 dage eller 12 måneder som diagram – de samme værdier, som vi også ser. Kun det, der er tilknyttet Deres virksomhed, er synligt.
Og når en grænseværdi overskrides, behøver De ikke gøre noget: Ticket er allerede hos os, med enhed, værdi og klokkeslæt, før De opdager det.
Hvad modulet bevidst ikke er
Det er ikke en erstatning for en fuldstændig overvågning med tilgængelighedskontroller, eskaleringskæder og afhængighedstræer. Det modtager ingen SNMP-traps, men forespørger aktivt. Og det lukker ikke noget ticket automatisk – afblæsningen er en besked, ikke en statusændring.
Det handler om netop én strækning: fra måleværdien over grænsen til teknikeren, der tager sig af det. Denne strækning er nu så kort, som den kan være.
Hvis De ønsker at optage Deres servere, netværksenheder eller sensorer i denne overvågning, så kontakt os.