Guía de Troubleshooting con CNS/ITSM
Guía de Troubleshooting con CNS/ITSM
Para: Operadores de red y administradores de infraestructura Sistema: CreaRack Network Sentinel (CNS) + ITSM Última actualización: 17-03-2026
1. Introduccion
CreaRack Network Sentinel (CNS) es el sistema de inteligencia artificial que monitorea tu infraestructura de red en tiempo real. Cuando detecta una anomalía (pérdida de paquetes, latencia elevada, errores de interfaz, caídas de clientes WiFi, etc.), genera un Insight: un diagnóstico completo con causa raíz, nivel de riesgo, y comandos recomendados para resolver el problema. El módulo ITSM complementa al CNS proporcionando gestión de incidentes: políticas SLA, notificaciones, escalamiento, y documentación de problemas conocidos.
CNS está disponible en tres páginas de monitoreo, cada una mostrando solo los insights relevantes a sus dispositivos:
| Página | Dispositivos monitorizados |
|---|---|
| Observatory | Electrónica de red (switches, routers, firewalls) + targets manuales |
| Wireless | Access Points WiFi |
| UPS Monitor | Sistemas de alimentación ininterrumpida |
2. El ciclo de vida de un Insight
Cada insight pasa por un ciclo de vida desde que se detecta la anomalía hasta su resolución:
Anomalía detectada por el Agent
│
▼
┌──────────┐
│ PENDING │ ← El insight espera acción del operador
└────┬─────┘
│
┌───────┼──────┐────────────┐
│ │ │
▼ ▼ ▼
┌───────────┐ ┌────────────┐ ┌─────────┐
│ APPLIED │ │ACKNOWLEDGED│ │ EXPIRED │
│(commands │ │(operador │ │(4h sin │
│ejecutados)│ │ confirma) │ │ acción) │
└────┬──────┘ └────────────┘ └─────────┘
│
├── OK ──→ APPLIED (éxito)
└── Error → FAILED (fallo)
Significado de cada estado
| Estado | Qué significa | Qué puedes hacer |
|---|---|---|
| Pending | El sistema ha diagnosticado un problema y espera tu decisión | Ver detalles, Aplicar fix, Hacer preguntas (Explain), Acknowledge |
| Executing | Los comandos se están ejecutando en el dispositivo | Esperar resultado (el insight está bloqueado) |
| Applied | Los comandos se ejecutaron correctamente | Verificar resultado, hacer rollback si es necesario |
| Acknowledged | Has confirmado que revisaste el insight | Caso cerrado. Visible en History |
| Expired | Pasaron 4 horas sin acción | Se archiva automáticamente. Consultable en History |
| Failed | La ejecución de comandos falló | Reintentar, aplicar rollback, o acknowledge |
3. Cuando aparece un Insight
Cuando el sistema detecta una anomalía, recibirás tres señales visuales:
Notificacion toast
Un mensaje emergente aparece brevemente en la esquina superior derecha con el nivel de riesgo y un resumen:
- Rojo: “AI Insight [HIGH]: Switch Core — BGP session down”
- Naranja: “AI Insight [MEDIUM]: AP-Sala3 — Packet loss elevated”
- Azul: “AI Insight [LOW]: Router Casa — Latency spike detected”
Punto pulsante en el sidebar
Junto al nombre del dispositivo afectado aparece un punto pulsante de color:
- Rojo — Riesgo HIGH: requiere atención inmediata
- Naranja — Riesgo MEDIUM: degradación del servicio
- Azul — Riesgo LOW: informativo, no urgente
Si un dispositivo tiene múltiples insights activos, el punto muestra el color del más severo.
Contador en la barra de stats
La pestaña CNS actualiza los contadores en la barra superior. El número de insights “Pending” aumenta.
4. Ejemplo 1: Insight de alta prioridad (HIGH)
Escenario: Un Access Point pierde conectividad con varios clientes WiFi.
Paso 1: Recibes la alerta
Estás en la página Wireless Monitor. Aparece un toast rojo: “AI Insight [HIGH]: AP-Nodal — Client disconnect storm”. Un punto rojo pulsante aparece junto a “AP-Nodal” en el sidebar.
Paso 2: Abres la pestaña CNS
Haces clic en la pestaña CNS en la barra superior. Ves la barra de stats con 1 insight Pending. En la tabla aparece:
| Case | Risk | Target | Summary | Status |
|---|---|---|---|---|
| CNS-000127 | HIGH | AP-Nodal (192.168.230.2) | Client disconnect storm — 15 clients dropped in 2 minutes | pending |
Paso 3: Revisas el detalle
Haces clic en Details. Se abre el modal con:
- Summary: “Client disconnect storm — 15 clients dropped in 2 minutes”
- Root Cause: “Radio 2.4GHz channel interference causing deauthentication frames. Channel utilization at 94%”
- Confidence: 82%
- Risk Level: HIGH — Afecta a múltiples usuarios
- Commands recomendados:
set radio 2.4ghz channel autoset radio 2.4ghz power 17
- Rollback:
set radio 2.4ghz channel 6/set radio 2.4ghz power 20
Paso 4: Haces una pregunta (Explain)
Antes de aplicar, quieres más contexto. Escribes: “¿Cuántos usuarios están afectados ahora mismo?” y haces clic en Explain. El sistema responde con un análisis contextual basado en la telemetría actual.
Paso 5: Aplicas el fix
Decides aplicar los comandos. Haces clic en Apply Fix. El estado cambia a “Executing”. Tras unos segundos, el Agent ejecuta los comandos via SSH y reporta éxito. El estado cambia a Applied.
Paso 6: Verificas el resultado
Revisas que los clientes se reconectan. Todo funciona. El insight queda como Applied y se archivará tras 4 horas.
5. Ejemplo 2: Insight informativo (LOW)
Escenario: Un router muestra un pico temporal de latencia.
Paso 1: Notificacion
Toast azul: “AI Insight [LOW]: Router Casa — Latency spike to 180ms”. Punto azul pulsante en el sidebar de Observatory.
Paso 2: Revisas el detalle
Abres CNS, clic en Details. El insight muestra:
- Summary: “Latency spike to 180ms (normal baseline: 12ms)”
- Root Cause: “Possible upstream ISP congestion during peak hours”
- Confidence: 65%
- Commands: (ninguno — el problema está fuera de tu red)
Paso 3: Acknowledges con nota
Como el problema es del ISP y no puedes actuar, haces clic en Acknowledge. Aparece un campo de texto donde escribes: “Pico de latencia ISP. Abierto ticket #4521 con proveedor.” Confirmas.
El insight pasa a estado Acknowledged con tu nota visible para el equipo.
6. Ejemplo 3: Insight que expira
Escenario: Error temporal de CRC en una interfaz que se autocorrige.
Lo que pasa
- El Agent detecta errores CRC elevados en un puerto del switch
- Se genera un insight MEDIUM: “Interface CRC errors above threshold”
- Antes de que nadie actúe, los errores vuelven a niveles normales
- Pasan 4 horas → el insight cambia automáticamente a Expired
- El insight desaparece de la vista principal pero queda consultable en History
Cuándo es normal que expiren
- Picos temporales de tráfico
- Reconexiones automáticas de protocolos (STP, RSTP)
- Interferencias WiFi puntuales
- Falsos positivos por umbrales muy sensibles
Si ves muchos insights expirando para el mismo dispositivo, considera ajustar los umbrales del Agent o documentarlo como Known Issue en ITSM.
7. Trabajando con la tabla CNS
Barra de estadísticas
Los 5 contadores en la parte superior son clickables. Al hacer clic en un contador, la tabla se filtra automáticamente por ese estado. Clic de nuevo para quitar el filtro.
| Contador | Significado |
|---|---|
| Total | Todos los insights (sin filtro) |
| Pending | Esperando acción del operador |
| Executing | Comandos en ejecución |
| Applied | Comandos ejecutados con éxito |
| Acknowledged | Confirmados por un operador |
| Success Rate | Porcentaje de insights aplicados vs total |
Filtros disponibles
- Status: filtra por estado (Pending, Executing, Applied, etc.)
- Risk Level: filtra por severidad (HIGH, MEDIUM, LOW)
- Buscar: busca por número de caso (CNS-000042), nombre de dispositivo, IP, resumen, o causa raíz
- Fechas: rango de fechas “desde” y “hasta”
- Clear: limpia todos los filtros de golpe
Acciones de la toolbar
- Export CSV: descarga todos los insights filtrados como archivo CSV (útil para informes)
- History: abre el historial de insights acknowledged (últimos 30 días)
- ITSM Settings: cambia a la pestaña ITSM para configuración de SLA, canales, etc.
Paginacion
La tabla muestra 25 insights por página. Usa los botones Prev/Next o los números de página.
Cada página muestra solo sus dispositivos
- En Observatory solo verás insights de switches, routers y targets manuales
- En Wireless solo verás insights de Access Points
- En UPS solo verás insights de sistemas UPS
- Esto evita ruido: cada equipo de trabajo ve solo lo relevante a su área
8. El modal de detalle
Al hacer clic en Details o en el resumen de un insight, se abre el modal con toda la información:
Campos principales
| Campo | Qué te dice |
|---|---|
| Summary | Diagnóstico en una frase. Qué está pasando |
| Root Cause | Por qué está pasando. Causa técnica identificada por la IA |
| Confidence | Del 0% al 100%. Cuánto confía la IA en su diagnóstico. >80% es fiable. <50% revisa manualmente |
| Risk Level | HIGH (crítico), MEDIUM (degradación), LOW (informativo) |
| OSI Layer | Capa de red afectada (1=Físico, 2=Enlace, 3=Red, 4=Transporte, 7=Aplicación) |
| Telemetry | Datos de monitoreo que provocaron la alerta (valores SNMP, latencia, etc.) |
| Action Label | Acción recomendada en lenguaje natural (ej: “Restart BGP session”) |
| Commands | Lista numerada de comandos SSH que el sistema puede ejecutar |
| Rollback | Comandos para deshacer el fix si algo sale mal |
Badges ITSM
Si tienes ITSM configurado, verás badges adicionales:
| Badge | Significado |
|---|---|
| SLA Ack (verde) | Tiempo para acknowledgar: cumplido |
| SLA Ack (rojo) | Tiempo para acknowledgar: VENCIDO |
| SLA Resolve (verde/rojo) | Tiempo para resolver: cumplido/vencido |
| Escalation L2 | El insight se ha escalado al nivel 2 (SLA vencido) |
| Known Issue: [titulo] | Coincide con un problema conocido documentado |
| Runbook: [titulo] | Existe un procedimiento paso a paso aplicable |
| Group: [titulo] | Este insight forma parte de un incidente correlacionado |
Botones de accion
| Botón | Cuándo usarlo |
|---|---|
| Apply Fix | Cuando confías en el diagnóstico y quieres ejecutar los comandos |
| Acknowledge | Cuando has revisado el insight pero no necesitas ejecutar comandos |
| Explain | Cuando necesitas más contexto antes de decidir |
| Revise | Cuando crees que el diagnóstico puede mejorar con tu feedback |
9. Preguntar al sistema (Explain)
La función Explain te permite hacer preguntas contextuales sobre cualquier insight. La IA tiene acceso completo al contexto del insight (datos SNMP, diagnóstico, comandos, historial) y responde en base a esa información.
Ejemplos de preguntas útiles
| Pregunta | Cuándo hacerla |
|---|---|
| “¿Qué otros dispositivos podrían estar afectados?” | Cuando sospechas un problema en cascada |
| “¿Esto puede esperar a mañana?” | Para evaluar urgencia |
| “¿Cuál es el riesgo de aplicar estos comandos?” | Antes de ejecutar un fix |
| “¿Hay alguna alternativa menos invasiva?” | Si los comandos te parecen agresivos |
| “Explícame la causa raíz en términos simples” | Si el diagnóstico es muy técnico |
| “¿Esto ha ocurrido antes en este dispositivo?” | Para detectar patrones |
Historial de conversacion
Cada pregunta y respuesta se guarda permanentemente en el insight. Si otro operador abre el mismo insight, verá todas las preguntas anteriores y las respuestas. Esto facilita el traspaso entre turnos.
El número entre paréntesis junto al resumen (ej: “(3)”) indica cuántas preguntas se han hecho sobre ese insight.
10. Configuracion ITSM
La pestaña ITSM contiene la configuración organizacional del sistema de gestión de incidentes. Estas configuraciones son compartidas en toda la organización (aplican a todas las páginas por igual).
SLA Policies (Acuerdos de Nivel de Servicio)
Define cuánto tiempo tiene el equipo para responder a cada nivel de riesgo:
| Risk Level | Ack (Acknowledgar) | Resolve (Resolver) |
|---|---|---|
| HIGH | 15 minutos | 60 minutos |
| MEDIUM | 30 minutos | 240 minutos (4h) |
| LOW | 60 minutos | 480 minutos (8h) |
Estos valores son personalizables. Si se excede el tiempo, el insight se marca como “SLA Breached” (incumplido) y se activan las escalaciones.
Para crear las políticas por defecto, haz clic en Initialize Default Policies la primera vez.
Notification Channels (Canales de Notificacion)
Configura dónde recibir alertas cuando ocurren eventos importantes:
| Tipo | Uso típico |
|---|---|
| Notificación al equipo NOC (una o varias direcciones) | |
| Slack | Canal de incidentes del equipo (#network-alerts) |
| Microsoft Teams | Canal de operaciones |
| Webhook | Integración con sistemas externos (ServiceNow, PagerDuty, etc.) |
Cada canal puede filtrarse por nivel de riesgo (ej: solo HIGH y MEDIUM al email del jefe).
Usa el botón Test para verificar que la configuración funciona antes de confiar en ella.
Escalation Policies (Políticas de Escalamiento)
Define qué pasa cuando se incumple un SLA:
- Nivel 1 (ej: 30 min sin respuesta): Notificar al canal del equipo
- Nivel 2 (ej: 1 hora sin respuesta): Notificar al responsable de turno
- Nivel 3 (ej: 2 horas sin respuesta): Notificar a dirección técnica
Cada nivel tiene un canal de notificación y un retraso configurable.
Maintenance Windows (Ventanas de Mantenimiento)
Programa periodos donde NO quieres recibir alertas:
- Ejemplo: “Actualización firmware switches — Sábado 02:00 a 04:00”
- Durante la ventana, los insights se suprimen (no se crean)
- Las notificaciones también se suprimen si está configurado
- Útil para evitar falsos positivos durante mantenimientos planificados
Known Issues (Problemas Conocidos)
Documenta problemas recurrentes y sus soluciones:
- Ejemplo: “AP-Puerta2 pierde clientes cada martes a las 14:00 por interferencia del microondas del comedor”
- Cuando un nuevo insight coincide con un Known Issue, aparece automáticamente el badge “Known Issue” en el detalle
- Incluye la resolución documentada para que cualquier operador pueda actuar
Runbooks (Procedimientos)
Guías paso a paso para resolver tipos específicos de problemas:
- Ejemplo: “Runbook: Recuperación de AP tras fallo de alimentación”
- Verificar estado LED
- Comprobar PoE en el switch
- Reiniciar puerto PoE
- Esperar 120 segundos
- Verificar asociación de clientes
Cuando un insight coincide con un runbook, aparece el badge “Runbook” en el detalle con enlace al procedimiento completo.
11. Patrones recurrentes y Grupos de incidentes
Patrones recurrentes
El sistema analiza automáticamente si un mismo dispositivo genera insights repetidos. Si detecta un patrón (mismo trigger, mismo dispositivo, frecuencia regular), lo muestra en la sección Recurring Patterns:
- Ejemplo: “AP-Hall.A — Packet loss spike: 5 ocurrencias en los últimos 7 días, cada día a las 13:00”
- Confianza: 87% — alta probabilidad de que sea un patrón real
- Acción recomendada: Investigar causa raíz (¿interferencia programada? ¿saturación a mediodía?)
Puedes marcar un patrón como Acknowledged para indicar que eres consciente de él. Los patrones no reconocidos se destacan visualmente.
Grupos de incidentes
Cuando múltiples insights ocurren al mismo tiempo y comparten la misma causa raíz, el sistema los agrupa automáticamente:
- Ejemplo: “5 APs perdieron conectividad a las 03:15 — Posible fallo de uplink”
- El grupo muestra todos los dispositivos afectados
- Puedes Resolver el grupo entero de una vez (marca todos los insights como acknowledged)
- Útil para incidentes que afectan a múltiples dispositivos (fallo de switch core, corte eléctrico, etc.)
12. Referencia rapida
Estados y colores
| Estado | Color | Accion disponible |
|---|---|---|
| Pending | Azul | Details, Apply, Acknowledge, Explain |
| Executing | Naranja | Solo lectura (esperando resultado) |
| Applied | Verde | Rollback, Acknowledge |
| Acknowledged | Gris | Solo lectura (caso cerrado) |
| Expired | Gris oscuro | Solo lectura (consultable en History) |
| Failed | Rojo | Reintentar, Rollback, Acknowledge |
Niveles de riesgo
| Nivel | Color | Significado | Tiempo SLA típico |
|---|---|---|---|
| HIGH | Rojo | Servicio interrumpido o degradación severa | Ack: 15 min, Resolve: 1h |
| MEDIUM | Naranja | Degradación parcial del servicio | Ack: 30 min, Resolve: 4h |
| LOW | Azul | Informativo, sin impacto inmediato | Ack: 1h, Resolve: 8h |
Atajos y consejos
| Accion | Cómo |
|---|---|
| Filtrar por un estado | Clic en el contador de la barra de stats |
| Buscar un caso específico | Escribe “CNS-000042” o solo “42” en el buscador |
| Ver solo insights críticos | Selecciona “HIGH” en el filtro de Risk Level |
| Exportar para informe | Clic en “Export CSV” (respeta los filtros activos) |
| Ver historial de casos cerrados | Clic en “History” |
| Ir a configuración ITSM | Clic en “ITSM Settings” en la toolbar CNS |
| Hacer pregunta sobre un insight | Abre Details → escribe pregunta → clic Explain |
Anomalías que detecta el sistema
| Tipo de anomalía | Umbral típico | Riesgo habitual |
|---|---|---|
| Pérdida de paquetes | >10% | HIGH |
| Latencia elevada | >200ms | MEDIUM |
| Errores CRC en interfaz | >100/min | MEDIUM |
| Caída de clientes WiFi | >30% en 5 min | HIGH |
| Interfaz down | Link down | HIGH |
| Saturación de ancho de banda | >90% capacidad | MEDIUM |
| Pico de temperatura | >70°C | LOW-MEDIUM |
Mantenido por: Equipo CreaRack Última actualización: 17-03-2026
Véase también
- [[concept—monitoring—cns]] — concepto del CreaRack Network Sentinel
- [[concept—monitoring—itsm]] — gestión de incidencias ITSM
- [[crearack—monitoring—cns-sentinel]] — CNS desde el punto de vista del usuario
- [[crearack—monitoring—itsm]] — ITSM orientado al usuario
- [[crearack-tech—guides—cns-guide]] — guía técnica de CNS
- [[crearack-tech—guides—itsm-guide]] — guía técnica de ITSM
- [[crearack-tech—agents—dev-cns]] — perfil de subagente dev-cns