Saltar al contenido principal

Diagnóstico de activos

Esta guía describe el flujo de diagnóstico estructurado para los escenarios más frecuentes relacionados con activos monitoreados en NetMonitor.

El objetivo es reducir el MTTR (tiempo promedio de recuperación) identificando rápidamente la causa raíz sin necesidad de acceder a consolas externas para los primeros pasos del diagnóstico.

[Imagen sugerida: vista de activo en alarma con pestañas Chassis, Interfaces y Asociaciones visibles]

Escenario 1: El activo está caído (en alarma de disponibilidad)​

Paso 1 — Verificar si el activo está efectivamente inalcanzable​

Acceder al activo desde la vista de alarmas o desde el mapa de topología. Verificar el estado actual: si el estado es "En alarma" con causa "Inaccesible", el activo no está respondiendo a los intentos de polling.

Antes de asumir que el activo cayó, verificar si hay un upstream caído que explique la inaccesibilidad.

Paso 2 — Revisar la pestaña Asociaciones​

La pestaña Asociaciones muestra los activos de los que depende este activo (upstream). Si el upstream está también en alarma, la causa raíz puede ser el upstream, no el activo analizado.

→ NetMonitor debería haber correlacionado estas alarmas automáticamente si las asociaciones están correctamente declaradas. Si no lo hizo, verificar la configuración de asociaciones en Asset Manager.

Paso 3 — Revisar el historial de disponibilidad en Chassis​

La pestaña Chassis muestra el historial de disponibilidad de las últimas 24 horas y el histórico. Verificar:

  • ¿Cuándo comenzó la caída?
  • ¿Hubo reinicios recientes (sysUptime)?
  • ¿El activo tiene historial de caídas frecuentes en este horario?

Paso 4 — Verificar el switch de acceso mediante CAM​

Si el activo está conectado a un switch monitoreado, buscar la dirección MAC del activo en la tabla CAM del switch de acceso:

  1. Abrir el Buscador de NetMonitor.
  2. Buscar por IP o MAC del activo.
  3. Verificar en qué switch y puerto aparece la MAC.
  4. Navegar a ese switch → pestaña Interfaces → verificar el estado del puerto.
Puerto del switch en Admin Down

Si el puerto del switch donde está conectado el activo está en estado "Admin Down", el problema no es el activo sino su conectividad de red. El activo puede estar operativo pero sin acceso a la red de gestión.

Paso 5 — Verificar el enlace upstream del sitio​

Si el activo está en una sucursal o sitio remoto y ese sitio completo está inaccesible, el problema puede ser el enlace WAN que conecta el sitio. Verificar el estado del enlace WAN correspondiente en el módulo de Gestión de enlaces.

Paso 6 — Intentar acceso alternativo​

Si NetMonitor no puede alcanzar el activo, verificar si hay otra ruta de acceso (consola fuera de banda, acceso físico, VPN secundaria) para determinar si el activo está encendido o si hay un corte eléctrico.

Escenario 2: El activo está en estado desconocido​

El estado desconocido en NetMonitor indica que la plataforma no pudo obtener datos del activo en el último ciclo de polling, pero no con suficiente certeza para declarar una caída.

Causas habituales​

CausaIndicios
Problema de SNMP (comunidad incorrecta, timeout)El activo responde a ICMP pero no a SNMP
Interfaz de gestión inactivaEl activo responde por otra IP pero no por la IP de gestión configurada
Congestión transitoria de redEl estado desconocido es intermitente y se auto-resuelve
SLA configurado en 0%NetMonitor no genera alarma pero sigue intentando comunicarse

Flujo de diagnóstico​

  1. Verificar si el activo responde a ICMP (ping desde el colector). Si responde a ICMP pero no tiene datos SNMP, el problema es la configuración SNMP.
  2. Verificar la configuración SNMP del activo en Asset Manager: comunidad, versión (v2c/v3), puerto, IP de gestión.
  3. Verificar si el NetCollector responsable del activo tiene conectividad al mismo.
  4. Revisar los logs del NetCollector para detectar errores de timeout o acceso denegado.

Escenario 3: El activo tiene alertas de recursos (CPU, memoria, temperatura)​

Las alertas de recursos indican que el activo está operativo pero con métricas fuera de los umbrales configurados.

Flujo de diagnóstico​

  1. Acceder a la pestaña Chassis del activo.
  2. Revisar el gráfico histórico del recurso en alerta: ¿es un pico puntual o una tendencia creciente?
  3. Si es un pico: correlacionarlo con eventos en el mismo horario (backup, actualización, reinicio).
  4. Si es una tendencia: analizar si la carga del activo creció gradualmente y se acerca al límite operativo.

Para CPU alta:

  • En la pestaña Procesos (si está disponible), identificar qué proceso está consumiendo CPU.
  • En firewalls: la pestaña Firewall puede mostrar si la alta CPU está correlacionada con un volumen de sesiones elevado.

Para memoria alta:

  • Verificar si la memoria está creciendo sostenidamente (posible memory leak) o si fluctúa con la carga normal.

Para temperatura alta:

  • Correlacionar con la temperatura del ambiente (sensores IoT del datacenter, si están monitoreados).
  • Verificar el estado de los ventiladores en la pestaña Chassis (inventario de componentes).

Escenario 4: El activo tuvo un reinicio inesperado​

NetMonitor detecta reinicios mediante el contador sysUptime SNMP y los TRAPs coldStart/warmStart.

Flujo de diagnóstico​

  1. Pestaña Chassis → sección Reinicios: verificar hora exacta del reinicio y tipo (coldStart, warmStart, o inferido por sysUptime).
  2. Correlacionar con la historia de alarmas del activo: ¿hubo una alarma de caída/recuperación en ese horario?
  3. Revisar si hubo un Config Change registrado cerca del reinicio (cambio de configuración que pudo haber provocado el reinicio).
  4. Si el reinicio fue inesperado (no había mantenimiento programado), escalar para investigar causa de hardware o software.

Próximos pasos​