CNS — CreaRack Network Sentinel

CNS — CreaRack Network Sentinel

Qué es

Motor de diagnóstico con inteligencia artificial de CreaRack Pro. Procesa telemetría SNMP, logs SSH y descripciones de anomalías para producir un AIInsight: objeto estructurado con diagnóstico, causa raíz, nivel de riesgo y comandos de mitigación listos para aprobación con un clic. System prompt identifica al sistema como “Network Sentinel AI”, motor de inferencia especializado en diagnósticos de red L3 (CCIE/JNCIE).

Por qué existe

La infraestructura gestionada genera anomalías complejas (pérdida de paquetes, ataques L2/WiFi, saturación, fallos STP) que requieren diagnóstico experto inmediato. CNS automatiza el primer nivel de triage, reduce MTTR y proporciona trazabilidad completa mediante audit log por cada acción sobre un insight.

Componentes

Proveedores AI (ai_providers/__init__.py → get_provider()):

Proveedor por defecto via settings.EDGE_AI_PROVIDER (default "google_genai", config/settings/base.py:314; actualizado 10-09-2026). Si el primario lanza excepción, insight_service.py reintenta automáticamente con StaticRulesProvider.

Rate limiting (_check_rate_limit()): ventana deslizante 1 hora.

• Por dispositivo: 5 insights/hora (RATE_LIMIT_PER_DEVICE = 5).
• Por tenant: 100 insights/hora (RATE_LIMIT_PER_TENANT = 100).

Si supera, ValueError antes de llamar al proveedor. Insights en maintenance window también suprimidos.

System prompt (prompts.py): restricciones no negociables — nunca sugerir reload, erase startup-config, write erase, format. rollback_commands obligatorios para riesgo MEDIUM/HIGH. Respuesta JSON válido con diagnosis + recommendation. Scope restringido a infraestructura de red.

Feedback loop (cns_feedback_loop.py): ciclo Detect → Diagnose → Act → Learn → Improve. Tarea Huey periódica ejecuta refresh_learned_patterns() cada 6h. Extrae patrones de:

1. Revisiones operadores (is_revised=True): corrección → regla aprendida.
2. Insights confirmados (status=ACKNOWLEDGED): causas raíz con ≥3 confirmaciones → patrones confiables.
3. InsightConversation frecuentes: preguntas repetidas loguean candidatos para enriquecimiento manual.

Patrones serializados en JSON y cacheados en Valkey (cns:learned_patterns, TTL 6h). StaticRulesProvider los consulta antes que reglas hardcodeadas. Umbral: 2 ocurrencias en revisiones, 3 en confirmaciones.

Flujos

Anomalía → Insight:

1. Agent detecta anomalía y llama create_insight() con target, snmp_data, ssh_logs, anomaly_description.
2. Verifica maintenance window y rate limits. Si falla, ValueError y no crea insight.
3. Proveedor AI recibe user prompt renderizado desde USER_PROMPT_TEMPLATE.
4. diagnosis_validator.py valida resultado; si score insuficiente, apply_adjustments() corrige antes de persistir.
5. Crea AIInsight con status PENDING, registra en AIInsightAuditLog.
6. Hooks ITSM: calcula deadlines SLA, correlaciona incidents, matchea runbooks, notifica, broadcast WS.

Apply / Rollback / Acknowledge:

• Apply: apply_insight() valida comandos contra vendor, transiciona a EXECUTING. Agent ejecuta y reporta via record_execution_result() → APPLIED o FAILED.
• Rollback: rollback_insight() valida rollback_commands y marca rollback_executed=True. Disponible desde APPLIED/EXECUTING.
• Acknowledge: acknowledge_insight() registra operador, timestamp, notas. Insights de pérdida de conectividad se auto-resuelven via auto_resolve_connectivity_insights() al recuperarse (keywords "total loss", "unreachable", "100%", "device down").
• Expiración: expire_stale_insights() marca EXPIRED los PENDING vencidos.

Related

• entity--monitoring--model--aiinsight — estructura resultante.
• entity--monitoring--model--monitoringtarget — origen de anomalías.
• concept--monitoring--itsm — capa ITSM que envuelve cada insight.

Véase también

• [[entity—monitoring—model—aiinsight]]
• [[entity—monitoring—model—monitoringtarget]]
• [[concept—monitoring—itsm]]