Monitorización SNMP en Odoo 19: se supera el límite y se abre un ticket
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 gestionamos para nuestros clientes, ahora hemos reunido todo ese proceso en un solo lugar: nuestro Odoo 19 consulta los dispositivos, compara los valores con los límites y, cuando se alcanza uno, abre un ticket en el servicio de asistencia asociado al cliente al que pertenece el dispositivo. En lugar de un sistema de monitorización independiente que envía correos al servicio de asistencia, utilizamos el mismo sistema en el que ya están relacionados el cliente, el dispositivo y el ticket.
Hemos desarrollado el módulo para nuestro propio uso. No es una publicación para la comunidad como nuestros módulos de extractos bancarios o facturación electrónica, sino una parte de nuestra plataforma interna de gestión de servicios, al igual que el sistema de localización del que hablamos recientemente.
Del valor medido al ticket
Hemos optado por un proceso sencillo:
- Se registra un dispositivo con su dirección y sus credenciales de acceso (SNMP v1, v2c o v3 con autenticación y cifrado). Al guardar, Odoo obtiene la descripción del sistema, su nombre y el tiempo de actividad: la confirmación más fiable de que la dirección y las credenciales son correctas.
- En el dispositivo se definen los puntos de datos: una OID, una unidad y un cliente asociado.
- Una tarea programada consulta todos los puntos de datos activos. Se establece una conexión por dispositivo, en lugar de una por cada punto de datos: con veinte OID en un switch, eso supone la diferencia entre una sesión y veinte.
- Cada punto de datos permite supervisar un límite superior, uno inferior o ambos.
- Si se supera un límite, se crea un ticket en el servicio de asistencia.
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 añade un aviso de normalización al mismo ticket y elimina la vinculación. La decisión de cerrar el ticket sigue en manos de una persona: que un valor baje momentáneamente del límite no significa que se haya resuelto la causa.
Los límites se comprueban en cada medición, independientemente de que se guarde el valor. Un valor que sigue siendo demasiado alto mantiene la alerta. Y una alerta nunca debe perderse porque no se pueda crear un ticket: si la creación falla, el registro y el mensaje se conservan en la ficha del dispositivo.
Guardar solo lo que cambia
Un punto de datos consultado cada cinco minutos genera 105.000 valores al año. Con cien puntos de datos, son más de diez millones de filas, en su mayoría para valores que no han cambiado.
Por eso solo se guardan los valores cuya diferencia respecto al último valor almacenado supera un umbral configurado para cada punto de datos: una diferencia absoluta (por ejemplo, 0,5 °C), una variación porcentual o cualquier cambio. El valor actual y la fecha y hora de la última consulta siguen estando siempre disponibles en el punto de datos; solo se reduce el volumen del historial.
También se puede configurar dónde se guardan los valores: en la base de datos de Odoo, en MongoDB o como archivos CSV en el almacén de archivos de Odoo. Así mantenemos las mediciones fuera de la base de datos del ERP, siguiendo el mismo principio que con los datos de posición del sistema de localización. En todos los casos, el historial se puede visualizar en un gráfico; al agrupar los datos por horas, se muestra la media, no la suma.
Nivel de ocupación en porcentaje en lugar de bytes
Algunas magnitudes no están disponibles directamente en el dispositivo. El nivel de ocupación de una partición debe calcularse a partir del espacio utilizado y la capacidad total; los sensores de temperatura suelen devolver números enteros escalados: 235 para indicar 23,5 grados.
Por eso, un punto de datos puede tomar el valor tal como se recibe, multiplicarlo por un factor o calcularlo como porcentaje de una segunda OID. Esto es fundamental para los límites: un límite del 90 % sirve para cualquier capacidad de disco. Un límite en gigabytes tendría que ajustarse para cada unidad.
No hace falta saberse las OID de memoria
En los servidores Windows y Linux, HOST-RESOURCES-MIB está normalizada: las unidades y la memoria RAM se encuentran en ubicaciones conocidas. La detección de dispositivos lee la tabla, convierte los niveles de ocupación a porcentajes y crea los puntos de datos con sus límites de alerta con un solo clic.
Para todo lo demás hay un explorador SNMP que recorre el árbol de OID y muestra cada OID encontrada con su valor actual y, si figura en el catálogo, con el nombre, la descripción y la unidad de la MIB del fabricante importada. Basta con marcar las casillas.
Qué ventajas ofrece a nuestros clientes
Los dispositivos y los puntos de datos están asociados a clientes. En el portal de clientes, en Mis valores SNMP, encontrará las mediciones actuales de sus dispositivos y un gráfico con el historial de las últimas 24 horas, 7 días, 30 días o 12 meses: los mismos valores que vemos nosotros. Solo se muestra lo que está asociado a su empresa.
Y si se supera un límite, usted no tiene que hacer nada: antes de que lo advierta, ya habremos recibido el ticket con el dispositivo, el valor y la hora.
Lo que este módulo no pretende ser
No sustituye a una solución completa de monitorización con comprobaciones de disponibilidad, cadenas de escalado y árboles de dependencias. No recibe traps SNMP, sino que realiza consultas activas. Tampoco cierra tickets automáticamente: el aviso de normalización es un mensaje, no un cambio de estado.
Se centra en un único recorrido: del valor medido que supera un límite al técnico que se encarga de resolverlo. Ahora ese recorrido es lo más corto posible.
Si desea incluir sus servidores, dispositivos de red o sensores en esta monitorización, póngase en contacto con nosotros.