Saltar al contenido principal

Buenas prácticas de configuración

Esta guía recoge las recomendaciones más importantes para configurar NetMonitor de forma que la plataforma sea útil, sostenible y escalable en el tiempo.

Una configuración bien diseñada desde el inicio reduce el ruido de alarmas, facilita el diagnóstico y hace que la plataforma crezca ordenadamente.


Activos y Asset Manager

Nomenclatura consistente

Definir y documentar una convención de nomenclatura antes de comenzar a cargar activos. Una vez que hay cientos de activos, renombrarlos es costoso.

Convenciones recomendadas:

CampoRecomendación
Nombre del activo<TIPO>-<SITIO>-<NÚMERO> Ej: SW-BSAS-01, FW-MDQ-01, SRV-CORP-03
EmplazamientoNombres completos y consistentes: Buenos Aires – DC Principal, no BA o bsas dc
Red/GrupoAgrupar por función operativa: Infraestructura Core, Sucursales, Servidores Producción
DescripciónBreve pero completa: modelo, número de serie, fecha de instalación, responsable

Configurar el SLA con criterio

El SLA no debe ser siempre el mismo para todos los activos:

Tipo de activoSLA sugerido
Activos de red críticos (core switches, firewalls)99.5% – 99.9%
Activos de infraestructura IT (servidores producción)99% – 99.5%
Activos secundarios (switches de acceso, APs)98% – 99%
Activos en prueba o no críticos0% (no genera alarmas de disponibilidad)

Completar asociaciones antes de poner en producción

Las asociaciones entre activos son la base de la correlación de alarmas. Si se cargan activos sin asociaciones:

  • NetMonitor no puede distinguir si la caída de un servidor es independiente o consecuencia de la caída de su switch de acceso.
  • En una tormenta de alarmas, el operador recibirá una alarma por cada activo afectado en lugar de una sola alarma de causa raíz.

Completar las asociaciones físicas (upstream/downstream) para al menos todos los activos críticos antes de comenzar a operar el monitoreo en producción.

Documentar en Asset Docs desde el inicio

La pestaña Chassis → Asset Docs de cada activo es el lugar para documentar procedimientos, accesos y notas operativas. Cada activo crítico debería tener al menos:

  • Modelo y número de serie
  • IP de gestión y credenciales de acceso (o referencia a donde se almacenan de forma segura)
  • Contacto del proveedor o del responsable técnico
  • Procedimiento de reinicio de emergencia

Umbrales y alertas

Usar la jerarquía de umbrales

Evitar configurar umbrales manualmente para cada activo individual si es posible. Usar la jerarquía:

  1. Definir umbrales globales razonables (ej: CPU > 85%, temperatura > 60°C).
  2. Sobreescribir a nivel de tipo de activo donde los valores globales no aplican (ej: firewalls toleran más CPU).
  3. Sobreescribir a nivel de componente específico solo cuando hay una razón clara.

Evitar el ruido de alertas

Una plataforma de monitoreo que genera demasiadas alertas sin importancia se convierte en ruido que el equipo aprende a ignorar — y entonces las alertas importantes se pierden.

Principios para minimizar el ruido:

  • No configurar umbrales demasiado bajos. Un umbral de CPU al 70% en un servidor que habitualmente corre al 65% generará alertas constantemente.
  • Usar el intervalo de recordatorio con criterio. Para alertas informativas, configurar 00:00:00 (sin recordatorio).
  • Revisar y ajustar umbrales después del primer mes de operación. Los primeros umbrales son siempre una estimación; los reales se conocen con datos históricos.
  • SLA=0% para activos en prueba o secundarios, para que no generen alarmas de disponibilidad mientras se configuran.

Notificaciones y canales

Diseñar la matriz de notificaciones antes de configurar

Antes de crear reglas y canales, definir:

  • ¿Qué tipos de eventos notifican a qué equipos?
  • ¿Hay horarios de guardia con distintos destinatarios?
  • ¿Cuáles son los eventos que requieren escalamiento inmediato vs. los que pueden esperar al siguiente turno?

Un canal por propósito

Evitar un único canal de notificación que recibe todo. En cambio, crear canales específicos:

CanalPropósito
Email NOC turno ANotificaciones durante el turno A
Telegram críticosSolo alarmas de severidad alta
Teams infraestructuraAlertas de servidores y hipervisores
Webhook ITSMCreación automática de tickets

Probar los canales antes de ponerlos en producción

Después de configurar un canal, enviarse un evento de prueba para verificar que el mensaje llega correctamente y con el formato esperado.


Mapas y topología

Declarar todos los enlaces LAN/MAN con detalle de panel y puerto

Los enlaces declarados sin detalle de panel/puerto solo muestran la relación lógica entre activos, pero no permiten usar el inspector ni el unifilar. Completar el detalle físico desde el inicio vale el esfuerzo: la documentación de planta física es difícil de reconstruir después.

Crear un mapa por rol operativo

No todos los operadores necesitan ver lo mismo:

  • Mapa NOC general: todos los activos críticos con su estado.
  • Mapa por sitio: solo los activos de una sucursal o datacenter específico.
  • Mapa de core de red: solo los activos de backbone y sus enlaces.

Los mapas propios de cada usuario reducen el tiempo de navegación durante un incidente.


Próximos pasos