Nadzor SNMP v Odoo 19: mejna vrednost presežena, zahtevek odprt
Strežniki, stikala, naprave UPS, temperaturna tipala v strežniški sobi: skoraj vse, kar visi v omrežju, govori SNMP in lahko poroča o svojem stanju. Vprašanje je le, kdo posluša – in kaj se zgodi, ko vrednost uide izpod nadzora.
Za infrastrukturo, ki jo vzdržujemo za svoje stranke, smo to verigo zdaj združili na enem mestu: naš Odoo 19 poizveduje pri napravah, primerja vrednosti z mejnimi vrednostmi, in ko je meja dosežena, odpre zahtevek v helpdesku – pri stranki, ki ji naprava pripada. Ne ločen sistem za nadzor, ki po e-pošti piše v helpdesk, temveč isti sistem, v katerem so stranka, naprava in zahtevek tako ali tako povezani.
Modul smo razvili za lastno poslovanje. Ni objava za skupnost kot naši moduli za bančne izpiske ali e-račune, temveč del naše interne platforme za vzdrževanje – tako kot sledenje, o katerem smo nazadnje poročali.
Od izmerjene vrednosti do zahtevka
Potek je namenoma preprost:
- Naprava se ustvari z naslovom in dostopnimi podatki (SNMP v1, v2c ali v3 z overjanjem in šifriranjem). Ob shranjevanju si Odoo pridobi opis sistema, ime sistema in uptime – najpošteneje potrdilo, da sta naslov in dostopni podatki pravilna.
- Na napravi se določijo podatkovne točke: OID, enota, dodelitev stranki.
- Urnik poizveduje po vseh aktivnih podatkovnih točkah. Za vsako napravo se poveže enkrat, ne za vsako podatkovno točko – pri dvajsetih OID na stikalu je to razlika med eno in dvajsetimi sejami.
- Vsaka podatkovna točka lahko nadzira mejne vrednosti: zgornjo mejo, spodnjo mejo ali oboje.
- Če je meja presežena, nastane zahtevek v helpdesku.
En zahtevek na incident, ne na meritev
Najpomembnejša točka v logiki alarmiranja: šteje le sprememba stanja. Kdor ustvari zahtevek ob vsaki meritvi, ima po noči z zagozdenim ali poskakujočim tipalom tristo zahtevkov – to ni alarmiranje, to je zamegljevanje.
Modul si zato za vsako podatkovno točko zapomni, ali je v stanju „Normalno“ ali „Alarm“. Ob prvem preseganju meje se stanje spremeni, v chatterju naprave pristane sporočilo in odpre se zahtevek – z zadevno stranko kot partnerjem, s podatkovno točko, napravo, izmerjeno vrednostjo in kršeno mejo v besedilu. Dokler vrednost ostaja zunaj meje, se nič več ne zgodi: zahtevek je odprt, naši tehniki vedo.
Ko se vrednost vrne v normalno območje, modul v isti zahtevek zapiše odpoved alarma in razveže povezavo. Ali se zahtevek nato zapre, še vedno odloči človek – vrednost, ki za kratek čas pade pod mejo, še ne pomeni, da je vzrok odpravljen.
Mejne vrednosti se preverjajo ob vsaki meritvi, ne glede na to, ali se vrednost shrani. Stalno previsoka vrednost ostane alarm. In alarm nikoli ne sme spodleteti zato, ker zahtevka ni mogoče ustvariti – če ustvarjanje spodleti, protokol in sporočilo pri napravi vseeno ostaneta.
Shranjevati le, kar se spremeni
Podatkovna točka, po kateri se poizveduje vsakih pet minut, da 105.000 vrednosti na leto. Pri sto podatkovnih točkah je to več kot deset milijonov vrstic – za vrednosti, ki se večinoma sploh niso spremenile.
Shrani se zato le tisto, kar se od zadnje shranjene vrednosti razlikuje za več kot nastavljen prag – za vsako podatkovno točko kot absolutna razlika (na primer 0,5 °C), kot odstotni odmik ali ob vsaki spremembi. Trenutna vrednost in čas zadnje poizvedbe sta vseeno vedno pri podatkovni točki; razredčen je le potek.
Kam se vrednosti zapisujejo, je prav tako nastavljivo: v zbirko podatkov Odoo, v MongoDB ali kot datoteke CSV v Odoo filestore. Meritve tako ohranjamo zunaj zbirke podatkov ERP – isto načelo kot pri podatkih o položajih pri sledenju. Potek je v vsakem primeru mogoče prikazati kot diagram, pri urni zgostitvi kot povprečje, ne kot vsoto.
Zapolnjenost v odstotkih namesto v bajtih
Nekatere količine v napravi niso na voljo kot take. Zapolnjenost particije je treba izračunati iz zasedenega pomnilnika in skupne velikosti; temperaturna tipala pogosto vračajo skalirana cela števila – 235 za 23,5 stopinje.
Podatkovna točka lahko zato prevzame vrednost, kot je sporočena, jo pomnoži s faktorjem ali izračuna kot odstotek druge OID. Za mejne vrednosti je to odločilno: meja 90 % velja za vsako velikost diska. Mejo v gigabajtih bi bilo treba vzdrževati za vsak pogon posebej.
Nihče si ne mora zapomniti OID-jev na pamet
Pri strežnikih Windows in Linux je HOST-RESOURCES-MIB standardiziran: pogoni in delovni pomnilnik so na znanem mestu. Prepoznavanje naprav prebere tabelo, preračuna zapolnjenost v odstotke in z enim klikom ustvari podatkovne točke skupaj z mejo alarma.
Za vse drugo obstaja brskalnik SNMP, ki prehodi drevo OID in vsako najdeno OID prikaže s trenutno vrednostjo – in, če je znana v katalogu, z imenom, opisom in enoto iz uvožene MIB proizvajalca. Zadošča kljukica.
Kaj imajo naše stranke od tega
Naprave in podatkovne točke so dodeljene strankam. V portalu strank pod Moje vrednosti SNMP najdete trenutne meritve svojih naprav in potek zadnjih 24 ur, 7 dni, 30 dni ali 12 mesecev kot diagram – iste vrednosti, ki jih vidimo tudi mi. Vidno je izključno tisto, kar je dodeljeno vašemu podjetju.
In ko je mejna vrednost presežena, vam ni treba storiti ničesar: zahtevek je pri nas že odprt, z napravo, vrednostjo in uro, še preden ga opazite.
Kar modul namenoma ni
Ni nadomestilo za popoln nadzor s preverjanji razpoložljivosti, eskalacijskimi verigami in drevesi odvisnosti. Ne sprejema pasti SNMP (traps), temveč poizveduje aktivno. In nobenega zahtevka ne zapre samodejno – odpoved alarma je sporočilo, ne sprememba stanja.
Gre za natanko eno pot: od izmerjene vrednosti prek meje do tehnika, ki poskrbi za stvar. Ta pot je zdaj tako kratka, kot lahko je.
Če želite svoje strežnike, omrežne naprave ali tipala vključiti v ta nadzor, se obrnite na nas.