Monitorización SNMP en Odoo 19: umbral superado, ticket abierto
Servidores, switches, SAI, sensores de temperatura en la sala de servidores: casi todo lo que cuelga de una red habla SNMP y puede informar de su estado. La cuestión es solo quién escucha y qué sucede cuando un valor se sale de madre.
Para la infraestructura que atendemos para nuestros clientes hemos reunido ahora esta cadena en un solo lugar: nuestro Odoo 19 consulta los dispositivos, compara los valores con los umbrales y, cuando se alcanza un límite, abre un ticket en el helpdesk, en el cliente al que pertenece el dispositivo. No un sistema de monitorización aparte que escribe por correo electrónico en el helpdesk, sino el mismo sistema en el que cliente, dispositivo y ticket ya están relacionados de todos modos.
Hemos desarrollado el módulo para nuestra propia operación. No es una publicación para la comunidad como nuestros módulos de extractos bancarios o facturas electrónicas, sino parte de nuestra plataforma interna de asistencia, igual que la localización de la que hemos informado recientemente.
Del valor medido al ticket
El flujo es deliberadamente sencillo:
- Se crea un dispositivo con dirección y credenciales de acceso (SNMP v1, v2c o v3 con autenticación y cifrado). Al guardar, Odoo obtiene la descripción del sistema, el nombre del sistema y el uptime, la confirmación más honesta de que la dirección y las credenciales son correctas.
- En el dispositivo se definen puntos de datos: un OID, una unidad, una asignación a un cliente.
- Una programación consulta todos los puntos de datos activos. Se conecta una vez por dispositivo, no por punto de datos; con veinte OID en un switch, esa es la diferencia entre una y veinte sesiones.
- Cada punto de datos puede vigilar umbrales: un límite superior, un límite inferior o ambos.
- Si se supera un límite, se crea un ticket de helpdesk.
Un ticket por incidente, no por medición
El punto más importante de la lógica de alarmas: solo cuenta el cambio de estado. Quien genera un ticket con cada medición tiene, tras una noche con un sensor atascado o con rebotes, trescientos tickets; eso no es alertar, eso es ofuscar.
Por eso el módulo recuerda, para cada punto de datos, si se encuentra en estado “Normal” o “Alarma”. Al superarse el límite por primera vez, el estado cambia, un mensaje llega al chatter del dispositivo y se abre un ticket, con el cliente afectado como contacto y con el punto de datos, el dispositivo, el valor medido y el límite vulnerado en el texto. Mientras el valor permanezca fuera del límite, no ocurre nada más: el ticket está abierto, nuestros técnicos están informados.
Cuando el valor vuelve al rango normal, el módulo escribe un aviso de fin de alarma en el mismo ticket y suelta el vínculo. Si el ticket se cierra entonces o no lo sigue decidiendo una persona: un valor que cae brevemente por debajo del límite todavía no significa que la causa esté resuelta.
Los umbrales se comprueban en cada medición, con independencia de si el valor se guarda. Un valor constantemente demasiado alto sigue siendo una alarma. Y una alarma nunca debe fallar porque no se pueda crear un ticket: si la creación falla, el registro y el mensaje en el dispositivo permanecen igualmente.
Guardar solo lo que cambia
Un punto de datos consultado cada cinco minutos produce 105.000 valores al año. Con cien puntos de datos son más de diez millones de filas, para valores que en su mayoría ni siquiera han cambiado.
Por eso solo se guarda lo que difiere del último valor guardado en más de un umbral configurado, por punto de datos como diferencia absoluta (por ejemplo 0,5 °C), como desviación porcentual o con cada cambio. El valor actual y el momento de la última consulta figuran siempre en el punto de datos; solo se aclara el historial.
También es configurable adónde se escriben los valores: en la base de datos de Odoo, en una MongoDB o como archivos CSV en el filestore de Odoo. Así mantenemos los valores medidos fuera de la base de datos del ERP, el mismo principio que con los datos de posición de la localización. En cualquier caso, el historial puede mostrarse como gráfico y, con la agregación por horas, como promedio, no como suma.
Nivel de llenado en porcentaje en lugar de en bytes
Algunas magnitudes no figuran como tales en el dispositivo. El nivel de llenado de una partición debe calcularse a partir de la memoria usada y el tamaño total; los sensores de temperatura suelen entregar enteros escalados: 235 para 23,5 grados.
Por eso un punto de datos puede adoptar el valor tal como se notifica, multiplicarlo por un factor o calcularlo como porcentaje de un segundo OID. Para los umbrales esto es decisivo: un límite del 90 % vale para cualquier tamaño de disco. Un límite en gigabytes tendría que mantenerse para cada unidad.
Nadie tiene que saberse los OID de memoria
En servidores Windows y Linux, la HOST-RESOURCES-MIB está normalizada: las unidades y la memoria RAM se encuentran en un lugar conocido. Una detección de dispositivos lee la tabla, convierte los niveles de llenado a porcentaje y crea con un clic los puntos de datos junto con el umbral de alarma.
Para todo lo demás hay un navegador SNMP que recorre el árbol de OID y muestra cada OID encontrado con su valor actual y, si es conocido en el catálogo, con nombre, descripción y unidad de la MIB del fabricante importada. Basta con marcar la casilla.
Qué obtienen nuestros clientes
Los dispositivos y los puntos de datos están asignados a clientes. En el portal de clientes encontrará, en Mis valores SNMP, los valores medidos actuales de sus dispositivos y el historial de las últimas 24 horas, 7 días, 30 días o 12 meses como gráfico: los mismos valores que vemos también nosotros. Solo es visible lo que está asignado a su empresa.
Y cuando se supera un umbral, usted no tiene que hacer nada: el ticket ya está con nosotros, con dispositivo, valor y hora, antes de que usted se dé cuenta.
Lo que el módulo deliberadamente no es
No es un sustituto de una monitorización completa con comprobaciones de disponibilidad, cadenas de escalado y árboles de dependencias. No recibe traps SNMP, sino que consulta activamente. Y no cierra ningún ticket automáticamente: el fin de la alarma es un mensaje, no un cambio de estado.
Se trata de un único recorrido: del valor medido, pasando por el umbral, hasta el técnico que se ocupa. Este recorrido es ahora tan corto como puede serlo.
Si desea incorporar sus servidores, dispositivos de red o sensores a esta supervisión, póngase en contacto con nosotros.