Monitoratge SNMP a Odoo 19: llindar superat, tiquet obert
Servidors, commutadors, sistemes d'alimentació ininterrompuda, sensors de temperatura a la sala de servidors: gairebé tot el que està connectat a una xarxa es comunica mitjançant SNMP i pot informar del seu estat. La qüestió és qui ho escolta i què passa quan un valor es descontrola.
Ara hem centralitzat tot aquest procés per a la infraestructura que gestionem per als nostres clients: el nostre Odoo 19 consulta els dispositius, compara els valors amb els llindars i, quan s'arriba a un límit, obre un tiquet al servei d'assistència, associat al client propietari del dispositiu. Tot passa en el mateix sistema on el client, el dispositiu i el tiquet ja estan relacionats, sense necessitat d'un sistema de monitoratge separat que enviï correus al servei d'assistència.
Hem desenvolupat el mòdul per al nostre ús intern. No és una publicació per a la comunitat com els nostres mòduls d'extractes bancaris o de factures electròniques, sinó que forma part de la nostra plataforma interna de gestió del servei, com la localització, de la qual vam parlar fa poc.
Del valor mesurat al tiquet
Hem mantingut el procés expressament senzill:
- Es crea un dispositiu amb l'adreça i les credencials d'accés (SNMP v1, v2c o v3 amb autenticació i xifratge). En desar-lo, Odoo n'obté la descripció del sistema, el nom del sistema i el temps de funcionament: la confirmació més fiable que l'adreça i les credencials són correctes.
- Es defineixen punts de dades per al dispositiu: un OID, una unitat i un client associat.
- Una tasca programada consulta tots els punts de dades actius. S’estableix una sola connexió per dispositiu, no per punt de dades: amb vint OID en un commutador, això marca la diferència entre una sessió i vint.
- Cada punt de dades pot supervisar valors límit: un límit superior, un d’inferior o tots dos.
- Quan un valor queda fora dels límits, es crea un tiquet de suport.
Un tiquet per incidència, no per mesurament
El punt més important de la lògica d'alarma: només compta el canvi d'estat. Qui crea un tiquet a cada mesura, després d'una nit amb un sensor encallat o que rebota té tres-cents tiquets: això no és alertar, és enterbolir.
Per això el mòdul recorda per a cada punt de dades si és en estat «Normal» o «Alarma». En superar el límit per primera vegada, l'estat canvia, un missatge arriba al chatter del dispositiu i s'obre un tiquet, amb el client afectat com a soci, amb punt de dades, dispositiu, valor mesurat i límit infringit al text. Mentre el valor es manté fora del límit, no passa res més: el tiquet és obert, els nostres tècnics ho saben.
Quan el valor torna a l’interval normal, el mòdul escriu un avís de fi d’alerta al mateix tiquet i en desfà la vinculació. La decisió de tancar el tiquet continua en mans d’una persona: que un valor baixi breument per sota del límit no vol dir que la causa s’hagi resolt.
Els valors límit es comproven en cada mesurament, tant si es desa el valor com si no. Un valor que es manté massa alt continua sent una alarma. I una alarma no pot fallar mai perquè no es pugui crear un tiquet: si la creació falla, el registre i el missatge es conserven igualment a la fitxa del dispositiu.
Desar només allò que canvia
Un punt de dades consultat cada cinc minuts proporciona 105.000 valors l’any. Amb cent punts de dades, això representa més de deu milions de files, per a valors que majoritàriament no han canviat gens.
Per això només es desen els valors que difereixen de l’últim valor desat en més d’un llindar configurat: per a cada punt de dades, es pot definir una diferència absoluta (per exemple, 0,5 °C), una desviació percentual o desar qualsevol canvi. El valor actual i la data i hora de l’última consulta continuen sempre disponibles al punt de dades; només es redueix el volum de l’historial.
També es pot configurar on s’escriuen els valors: a la base de dades d’Odoo, en una MongoDB o com a fitxers CSV al magatzem de fitxers d’Odoo. Així mantenim els valors mesurats fora de la base de dades de l’ERP, seguint el mateix principi que amb les dades de posició de la localització. En tots els casos, l’historial es pot mostrar en un gràfic; quan les dades s’agrupen per hores, se’n mostra la mitjana, no la suma.
Nivell d’ocupació en percentatge en lloc de bytes
Algunes magnituds no estan disponibles directament al dispositiu. El nivell d’ocupació d’una partició s’ha de calcular a partir de l’espai utilitzat i la capacitat total; els sensors de temperatura sovint proporcionen enters escalats: 235 per a 23,5 graus.
Per això, un punt de dades pot prendre el valor tal com es rep, multiplicar-lo per un factor o calcular-lo com a percentatge d’una segona OID. Això és decisiu per als valors límit: un límit del 90 % serveix per a qualsevol capacitat de disc. Un límit en gigabytes s’hauria d’ajustar per a cada unitat.
No cal que ningú se sàpiga les OID de memòria
Als servidors Windows i Linux, la HOST-RESOURCES-MIB està estandarditzada: les unitats i la memòria RAM es troben en ubicacions conegudes. Una funció de detecció de dispositius llegeix la taula, converteix els nivells d’ocupació en percentatges i crea els punts de dades amb el límit d’alarma amb un sol clic.
Per a la resta, hi ha un navegador SNMP que recorre l’arbre d’OID i mostra cada OID trobada amb el seu valor actual i, si consta al catàleg, amb el nom, la descripció i la unitat de la MIB del fabricant importada. Només cal marcar les caselles.
Què hi guanyen els nostres clients
Els dispositius i els punts de dades estan assignats als clients. Al portal de clients, a Els meus valors SNMP, hi trobareu els valors mesurats actuals dels vostres dispositius i un gràfic amb l’historial de les últimes 24 hores, 7 dies, 30 dies o 12 mesos: els mateixos valors que veiem nosaltres. Només hi és visible allò que està assignat a la vostra empresa.
I si se supera un valor límit, no heu de fer res: abans que us n’adoneu, ja hem rebut el tiquet amb el dispositiu, el valor i l’hora.
Què s’ha deixat expressament fora de l’abast del mòdul
No substitueix un sistema complet de monitoratge amb comprovacions de disponibilitat, cadenes d’escalat i arbres de dependències. No rep notificacions SNMP de tipus trap, sinó que fa consultes actives. I no tanca cap tiquet automàticament: l’avís de fi d’alerta és un missatge, no un canvi d’estat.
Es tracta d’un únic recorregut: del valor mesurat que supera el límit al tècnic que se n’ocupa. Ara aquest recorregut és tan curt com pot ser.
Si voleu incloure els vostres servidors, dispositius de xarxa o sensors en aquest monitoratge, poseu-vos en contacte amb nosaltres.