Monitoreo y control seguro de una flota de sistemas de energía CC sobre SNMP

Cada sitio de telecomunicaciones funciona con corriente continua (DC). Detrás de los radios y los routers hay una estantería rectificadora: una planta Eltek que convierte la alimentación de red en un limpio −48 V y realiza la carga flotante de una batería que debe mantener el sitio durante un apagón. Cuando una de esas plantas funciona mal, quieres saberlo antes de que lo haga la batería. Este es el sistema que construí para vigilar a toda una flota — y, eventualmente, para dirigirla.

De un script de informes a un sistema en vivo

La herramienta que reemplazó era un único script que generaba un par de informes HTML estáticos: la historia de ayer, congelada. Yo quería el estado en vivo, un historial de lo que cambió y la parte que convierte un panel de control en una herramienta: la capacidad de actuar sobre un controlador sin iniciar sesión manualmente en él.

La flota no es uniforme. Dos familias de controladores (el clásico Smartpack-1 y el más nuevo Smartpack-R / eNexus), diferentes MIBs, diferentes peculiaridades. Así que el núcleo tenía que ser agnóstico al proveedor y permitir a un operador enseñarle un nuevo controlador sin cambiar código.

Descubrimiento → clasificar → consultar (poll)

Tres módulos programados alimentan todo:

• Discovery extrae la lista de hosts de Zabbix (la red ya está inventariada allí) y la almacena en caché.
• Classify sondea cada host: realiza un SNMP-get de una OID de identidad para cada perfil de controlador conocido, y el primer perfil que responde gana; ese host es ahora un sistema de alimentación conocido de esa familia. Los hosts que no responden caen en un cubo Desconocido.
• Poll realiza un SNMP-walk de cada sistema clasificado cada 15 minutos, utilizando las OIDs escalares y columnas de tabla exactas definidas en su perfil, y renderiza el panel de control.

Lo que hace extensible esto es que classify y poll son impulsados por perfiles. Un perfil es simplemente un diccionario de OID: una OID de identidad, OIDs escalares (voltaje de entrada, temperatura, puntos de ajuste de flotación/impulso…) y columnas de tabla (una fila por ranura rectificadora). Residen en la base de datos y se editan en la interfaz de usuario. Añadir un proveedor nuevo — digamos una planta Huawei — es definir un perfil, no enviar código. Tú lo autores contra un dispositivo de muestra con un botón Probe que emite snmpget en vivo y te muestra exactamente lo que regresa, y luego promocionas un host coincidente a un sistema activo.

Inventario que no grita falsas alarmas

Consultar produce dos cosas: métricas en vivo y un inventario de componentes: cada módulo rectificador y unidad de control, por número de serie, ranura, revisión de hardware y firmware. Compara dos consultas consecutivas y obtienes eventos instalado / eliminado / cambiado, enviados por correo electrónico a quien sea responsable de ese sitio.

La parte difícil del diff de inventario no es el diff — no es mentir. SNMP sobre una red inestable pierde paquetes; un único fallo de consulta no debe hacer sonar la alarma a las 3 a.m. sobre un rectificador que nunca se fue. Dos salvaguardias manejan eso:

• Verificación de sanidad — si un escalar dice "8 rectificadores" pero la tabla de rectificadores regresó vacía, es un fallo parcial de SNMP, no una eliminación masiva. Ese componente se marca como no confiable para este pase y no se disparan eventos eliminado.
• Período de gracia — un componente debe faltar durante tres consultas consecutivas (~45 minutos) antes de declararse eliminado. Las ausencias puntuales permanecen silenciosas.

Y la primera consulta de un sitio recién incorporado está suprimida por arranque — incorporar cien sitios a la vez no debería bombardear la lista de correo con cien correos de "componente nuevo".

De leer a escribir: SNMP SET con salvaguardias

Monitorear es la mitad fácil. La mitad interesante es permitir que un operador cambie un controlador — voltaje de flotación e impulso, límite de corriente de carga, umbrales de alarma — desde el navegador, sobre SNMP, sin iniciar sesión por SSH en una planta de baterías activa.

Escribir a sistemas de alimentación es exactamente donde quieres paranoia. Cada SET sigue el mismo ciclo:

editar un parámetro
   │
   ├─ validar contra la MIB     (tipo · enum · rango → rechazar fuera de límites)
   ├─ ¿crítico para la batería? ───────────→ requiere confirmación explícita
   ├─ SET
   ├─ leer el valor DE VUELTA          (desajuste = el cambio FALLÓ, no tuvo éxito)
   └─ escribir un registro de auditoría        (quién · qué · antiguo → nuevo) · reversión con un clic

La lectura de vuelta es el paso que soporta la carga. Una respuesta SNMP SET exitosa no significa que el controlador haya respetado el valor — por lo que el sistema lee la OID de vuelta y solo considera realizado el cambio si el dispositivo reporta ahora lo que se le pidió. Los valores fuera de rango son rechazados antes de salir de la aplicación; los críticos para la batería — los voltajes que deciden si una cadena hierve o se descarga en exceso — no procederán sin una confirmación deliberada; y cada cambio revierte a su valor anterior con un solo botón.

El catálogo de OID escribibles se construye a partir de las MIBs del proveedor, no se escribe a mano. La MIB ya codifica el tipo, rango y acceso de cada OID, por lo que las reglas de seguridad provienen de la fuente de verdad en lugar de una suposición.

La prueba de la batería

Un control merece su propio párrafo. Una prueba de batería descarga deliberadamente la cadena para medir su capacidad real — útil, y también precisamente lo que no quieres activar casualmente con la red ya inestable. Es un único botón en el panel de control que advierte antes de comenzar, luego vuelve a comprobar ese sistema en vivo una vez por minuto mientras se ejecuta la prueba; cuando el controlador alcanza su voltaje final mínimo (o dispara una alarma) termina la prueba por sí mismo y el botón vuelve automáticamente. La interfaz de usuario nunca adivina el estado — lo lee del controlador.

Alcanzando el dispositivo sin su contraseña

La última pieza une "el rastreador" y "la propia interfaz web del controlador". Cada dispositivo tiene una interfaz web nativa, pero distribuir contraseñas de dispositivos no escala y no audita. En su lugar, un usuario autenticado hace clic en Web UI y aterriza en la interfaz propia del controlador, reenviado por proxy detrás del mismo inicio de sesión — el proxy está controlado por la sesión del rastreador e inyecta las credenciales del dispositivo almacenadas, para que el operador nunca las vea. La configuración del proxy por dispositivo se genera a partir del inventario, nunca se mantiene a mano: la flota cambia, la configuración regenera, valida y recarga — o revierte. Los secretos de los dispositivos están cifrados en reposo; el texto plano nunca llega a la base de datos.

Su forma

FastAPI + APScheduler, PostgreSQL, SNMP, una interfaz de usuario Jinja renderizada por servidor, todo en Docker. Pero el framework nunca fue el punto. El punto es una idea aplicada en todo: tratar al dispositivo como fuente de verdad y verificar contra él. Clasificar por lo que el dispositivo realmente responde; declarar un componente desaparecido solo cuando realmente ha desaparecido; llamar a un parámetro cambiado solo cuando el controlador lo lee de vuelta. Monitorear te dice qué es — la ingeniería interesante es hacer algo con ello sin empeorar las cosas.