Problema

En entornos medianos y grandes es habitual combinar varias soluciones para cubrir monitoreo, descubrimiento de topología, gestión de direcciones IP (IPAM) y escalado de alertas. Cada herramienta aporta una pieza: un sistema de métricas, otro para diagramas de red, otro para bases de datos de direcciones, y un tercero para on‑call. Cuando el número de nodos crece, la orquestación de credenciales, la sincronización de inventario y la consistencia de los eventos se vuelve frágil. Los síntomas típicos son:

  • Duplicación de datos entre bases de inventario.
  • Alertas perdidas o duplicadas al cruzar sistemas.
  • Configuraciones de credenciales dispersas que se vuelven difíciles de auditar.
  • Incremento del tiempo de respuesta ante incidentes porque la información está fragmentada.

El reto es consolidar esas funciones en una única plataforma que siga siendo auto‑alojada y que permita escalar sin que el número de nodos impacte la licencia de monitoreo.

Causa

Las causas más frecuentes de este desorden son:

  1. Elección de herramientas puntuales – Se selecciona una solución especializada (por ejemplo, Zabbix para métricas) sin evaluar la superposición con otras que ya están en uso.
  2. Falta de API unificada – Cada producto expone su propia API; la integración manual genera scripts ad‑hoc que se rompen con actualizaciones.
  3. Gestión de credenciales aislada – Los agentes de cada herramienta almacenan sus credenciales en archivos locales o en vaults diferentes, lo que dificulta la rotación y el control de acceso.
  4. Descubrimiento de dispositivos fragmentado – Algunos sistemas usan SNMP, otros ICMP, y la información de IPAM se mantiene en una base separada, lo que genera “ciegos” en la red.
  5. Escalado de alertas sin contexto – Los sistemas de on‑call suelen recibir sólo el mensaje de alerta, sin datos de topología o historial de incidentes, lo que retrasa la resolución.

Solución

Una solución genérica consiste en migrar a una plataforma de monitoreo on‑premise que integre:

  • Recolección de métricas (agent/collector) vía HTTPS, SNMP y API de virtualización.
  • Descubrimiento automático con escaneo ICMP/TCP/SNMP y correlación de resultados.
  • IPAM integrado que actúe como fuente de verdad para asignar dispositivos a sitios y subredes.
  • Generación de topología basada en datos de descubrimiento y en la información de IPAM.
  • Motor de alertas con reglas predefinidas y capacidad de escalado a equipos de respuesta (email, Teams, Slack, SMS, webhook).
  • Gestión de credenciales centralizada con cifrado AES‑256‑GCM y rotación automática.
  • RBAC y SSO para limitar el acceso a operadores, administradores y visualizadores.

Los pasos para adoptar esta arquitectura son:

  1. Inventario de componentes actuales – Listar todas las fuentes de métricas, bases de IPAM y sistemas de alerta. Identificar solapamientos y dependencias.
  2. Selección de la plataforma unificada – Elegir una solución que ofrezca los módulos descritos y que sea distribuible como paquete único (por ejemplo, un MSI para Windows Server). Verificar que el modelo de licenciamiento cuente nodos monitorizados y que los dispositivos solo escaneados por IPAM no consuman licencias.
  3. Plan de migración por fases
    • Fase 1 – Instalación del servidor – Desplegar la aplicación en un servidor Windows dedicado. Configurar FQDN y certificado Let’s Encrypt para comunicaciones TLS.
    • Fase 2 – Configuración de coleccionistas – Instalar agentes en cada segmento de red. Cada agente se registra con un token único; el servidor genera la clave API y la almacena con hash bcrypt.
    • Fase 3 – Importación de subredes – Cargar la información de IPAM existente (CSV, API o escaneo) para que el motor asocie automáticamente los dispositivos descubiertos a sus sitios.
    • Fase 4 – Definición de plantillas – Aplicar plantillas de monitoreo (switch, firewall, VM, etc.) a los grupos de dispositivos. Las plantillas incluyen métricas, umbrales y reglas de alerta.
    • Fase 5 – Configuración de escalado – Crear equipos de on‑call, asignar canales de notificación y definir horarios de silencio.
    • Fase 6 – Validación y corte – Desactivar los antiguos sistemas una vez que la nueva plataforma genere dashboards y alertas consistentes.
  4. Automatización de despliegue – Utilizar scripts de PowerShell o Ansible para registrar agentes y aplicar plantillas, garantizando idempotencia.
  5. Monitoreo de la propia plataforma – Configurar alertas internas para la disponibilidad de coleccionistas y la expiración de certificados TLS.

Cuándo aplicar esta solución

Aplicable cuando se cumplan al menos dos de los siguientes indicadores:

  • Más de tres herramientas diferentes gestionando la misma capa (métricas, topología, IPAM, alertas).
  • Incidentes recurrentes de alertas perdidas o duplicadas.
  • Necesidad de auditoría de credenciales y cumplimiento de normativas (ej. GDPR, ISO 27001).
  • Crecimiento previsto de nodos que superará los límites de licenciamiento de las herramientas actuales.

No es necesario si la infraestructura es muy pequeña (menos de 20 nodos) y la complejidad de integración no supera el coste operativo de mantener varios sistemas.

Código

# Instalación del MSI en modo silencioso
msiexec /i Stratora-Community.msi /quiet /norestart

# Registro de un agente remoto (ejemplo PowerShell)
$token = "YOUR_ENROLLMENT_TOKEN"
Invoke-WebRequest -Uri "https://stratora.example.com/api/v1/agents/enroll" `
    -Method POST -Headers @{ "Authorization" = "Bearer $token" } `
    -OutFile "C:\Program Files\Stratora\agent\agent.conf"

Verificación

  1. Conexión TLS – Acceder a https://stratora.example.com y confirmar que el certificado provisto por Let’s Encrypt es válido (fecha de expiración > 30 días).
  2. Descubrimiento – Ejecutar una exploración de red desde la UI y comprobar que aparecen al menos 95 % de los dispositivos esperados. Verificar que los dispositivos sin agente aparecen como “IP‑only” y no consumen una licencia.
  3. Alertas – Generar una condición de prueba (por ejemplo, detener el agente de un nodo) y observar que la notificación llega al canal configurado (Slack, Teams, etc.).
  4. Dashboard – Revisar que el dashboard del sitio muestra métricas en tiempo real y que la topología refleja enlaces activos.
  5. RBAC – Iniciar sesión con una cuenta de “Viewer” y confirmar que solo se pueden visualizar dashboards, sin opciones de edición.

Notas adicionales

  • Rotación de credenciales – Programa una tarea semanal que re‑genere las contraseñas de SNMP v3 y actualice el vault interno mediante la API.
  • Escaneo de redes OT – Si la red está segmentada, despliega coleccionistas en cada zona y habilita la opción “IPAM scanning from remote collectors” para evitar que el tráfico atraviese firewalls internos.
  • Licenciamiento – Aprovecha que los dispositivos escaneados pero no monitorizados no consumen slots; esto permite mantener una visión completa del espacio de direcciones sin inflar la cuenta de nodos.
  • Backup de la base de datos – Programa copias diarias de PostgreSQL y VictoriaMetrics; la restauración de métricas históricas es esencial para análisis de tendencias.
  • Extensibilidad – La plataforma expone webhooks compatibles con RFC 5424; pueden integrarse con Splunk o Elastic para enriquecer los logs de auditoría.