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​