Monitorización SNMP en Odoo 19: límite superado, ticket aberto
Servidores, switches, SAI, sensores de temperatura na sala de servidores: case todo o que está conectado a unha rede fala SNMP e pode informar do seu estado. A pregunta é só quen escoita – e que pasa cando un valor se sae de madre.
Para a infraestrutura que atendemos para os nosos clientes, colocamos agora esta cadea nun único lugar: o noso Odoo 19 consulta os dispositivos, compara os valores cos límites e, cando se alcanza un límite, abre un ticket no helpdesk – no cliente ao que pertence o dispositivo. Non un sistema de monitorización separado que escribe por correo electrónico ao helpdesk, senón o mesmo sistema no que cliente, dispositivo e ticket xa están relacionados de todos modos.
O módulo desenvolvémolo para a nosa propia operación. Non é unha publicación para a comunidade como os nosos módulos de extractos bancarios ou de facturas electrónicas, senón parte da nosa plataforma interna de atención – como a localización, sobre a que informamos recentemente.
Do valor medido ao ticket
O proceso mantense deliberadamente sinxelo:
- Créase un dispositivo con enderezo e datos de acceso (SNMP v1, v2c ou v3 con autenticación e cifrado). Ao gardar, Odoo obtén a descrición do sistema, o nome do sistema e o uptime – a confirmación máis honesta de que o enderezo e os datos de acceso son correctos.
- No dispositivo defínense puntos de datos: un OID, unha unidade, unha asignación a un cliente.
- Un calendario consulta todos os puntos de datos activos. Por dispositivo conéctase unha vez, non por punto de datos – con vinte OID nun switch, esa é a diferenza entre unha e vinte sesións.
- Cada punto de datos pode vixiar límites: un límite superior, un límite inferior ou ambos.
- Se se supera un límite, xorde un ticket de helpdesk.
Un ticket por incidencia, non por medición
O punto máis importante da lóxica de alarmas: só conta o cambio de estado. Quen xera un ticket con cada medición ten, despois dunha noite cun sensor atascado ou con rebotes, trescentos tickets – iso non é alarmar, é enevoar.
Por iso o módulo lembra, para cada punto de datos, se está no estado “Normal” ou “Alarma”. Ao superar o límite por primeira vez, o estado cambia, unha mensaxe aparece no chatter do dispositivo e ábrese un ticket – co cliente afectado como socio, con punto de datos, dispositivo, valor medido e límite infrinxido no texto. Mentres o valor permaneza fóra do límite, non pasa nada máis: o ticket está aberto, os nosos técnicos están informados.
Cando o valor volve ao rango normal, o módulo escribe un aviso de fin da alarma no mesmo ticket e desfai o vínculo. Se o ticket se pecha entón, segue decidíndoo unha persoa – un valor que cae brevemente por debaixo do límite aínda non significa que a causa estea resolta.
Os límites compróbanse en cada medición, independentemente de se o valor se garda. Un valor constantemente demasiado alto segue sendo unha alarma. E unha alarma nunca pode fallar porque non se poida crear un ticket – se a creación falla, o rexistro e a mensaxe no dispositivo quedan igualmente.
Gardar só o que cambia
Un punto de datos que se consulta cada cinco minutos xera 105.000 valores ao ano. Con cen puntos de datos son máis de dez millóns de liñas – para valores que na maioría dos casos nin sequera cambiaron.
Por iso só se garda o que difire do último valor gardado en máis dun limiar axustado – por punto de datos como diferenza absoluta (por exemplo 0,5 °C), como desviación porcentual ou con cada cambio. O valor actual e o momento da última consulta están sempre, a pesar de todo, no punto de datos; só se reduce o historial.
Onde se escriben os valores tamén se pode axustar: na base de datos de Odoo, nunha MongoDB ou como ficheiros CSV no filestore de Odoo. Así mantemos os valores medidos fóra da base de datos do ERP – o mesmo principio que cos datos de posición da localización. O historial pódese mostrar en todo caso como diagrama, e na condensación por horas como media, non como suma.
Nivel de ocupación en porcentaxe en vez de en bytes
Algunhas magnitudes non figuran como tales no dispositivo. O nivel de ocupación dunha partición hai que calculalo a partir da memoria ocupada e do tamaño total; os sensores de temperatura adoitan devolver enteiros escalados – 235 para 23,5 graos.
Un punto de datos pode, por iso, adoptar o valor tal como se comunica, multiplicalo por un factor ou calculalo como porcentaxe doutro OID. Para os límites isto é decisivo: un límite do 90 % vale para calquera tamaño de disco. Un límite en gigabytes tería que manterse para cada unidade.
Ninguén ten que saber de memoria os OID
En servidores Windows e Linux a HOST-RESOURCES-MIB está normalizada: as unidades e a memoria principal están nun lugar coñecido. Unha detección de dispositivos le a táboa, converte os niveis de ocupación en porcentaxe e crea os puntos de datos co seu límite de alarma cun clic.
Para todo o demais hai un navegador SNMP que percorre a árbore de OID e mostra cada OID atopado co seu valor actual – e, se se coñece no catálogo, con nome, descrición e unidade da MIB do fabricante importada. Abonda con marcalo.
O que obteñen os nosos clientes
Os dispositivos e puntos de datos están asignados a clientes. No portal de clientes atopa en Os meus valores SNMP os valores medidos actuais dos seus dispositivos e o historial das últimas 24 horas, 7 días, 30 días ou 12 meses como diagrama – os mesmos valores que vemos tamén nós. Só é visible o que está asignado á súa empresa.
E se se supera un límite, vostede non ten que facer nada: o ticket xa está connosco, con dispositivo, valor e hora, antes de que vostede o note.
O que o módulo deliberadamente non é
Non é un substituto dunha monitorización completa con comprobacións de dispoñibilidade, cadeas de escalado e árbores de dependencias. Non recibe traps SNMP, senón que consulta de forma activa. E non pecha ningún ticket automaticamente – o fin da alarma é unha mensaxe, non un cambio de estado.
Trátase exactamente dun tramo: do valor medido, a través do límite, ata o técnico que se ocupa. Ese tramo é agora tan curto como pode ser.
Se quere incorporar os seus servidores, dispositivos de rede ou sensores a esta vixilancia, póñase en contacto connosco.