Monitoreo proactivo¶
Configura un sistema de monitoreo inteligente que detecta y analiza problemas automáticamente.
Objetivo¶
Al final de esta guía tendrás:
- ✅ Monitoreo continuo de servicios
- ✅ Análisis automático de anomalías
- ✅ Alertas inteligentes (sin spam)
- ✅ Reportes de incidentes con contexto
Prerrequisitos¶
- Servicios/APIs a monitorear
- Canales de notificación configurados
- Acceso a logs y métricas
Arquitectura del sistema¶
graph TD
A[Tareas de monitoreo] -->|Cada 5 min| B[Health checks]
B --> C{Problema?}
C -->|Sí| D[Agente analiza]
D --> E[Determina severidad]
E --> F{Crítico?}
F -->|Sí| G[Alerta inmediata]
F -->|No| H[Agrupa con similares]
H --> I[Alerta resumida cada hora]
G --> J[Crea issue en backlog]
C -->|No| K[Log OK]Paso 1: Crea la tarea de health check¶
Prompt:
Realiza health check de todos los servicios críticos.
## Servicios a verificar:
### API Principal
- URL: ${API_URL}/health
- Timeout: 10 segundos
- Esperado: status 200, response.healthy = true
### Base de datos
- Verificar conexión activa
- Query de prueba: SELECT 1
- Timeout: 5 segundos
### Cache (Redis)
- Verificar conexión
- Comando PING
- Timeout: 3 segundos
### Cola de mensajes (RabbitMQ)
- Verificar conexión
- Revisar colas acumuladas (alerta si > 1000)
### Servicios externos
- Stripe API: verificar conectividad
- SendGrid: verificar API key válida
- S3: verificar acceso al bucket
## Output estructurado:
```json
{
"timestamp": "ISO date",
"overall_status": "healthy|degraded|critical",
"services": [
{
"name": "string",
"status": "ok|warning|error",
"latency_ms": number,
"details": "string"
}
],
"issues": ["string"]
}
Reglas de estado:¶
- healthy: Todos los servicios OK
- degraded: Algún servicio con warning o servicio no crítico caído
- critical: Servicio crítico caído o múltiples servicios afectados
Nombre: analyze-anomalies
Trigger: Cuando monitor-services-health reporta problema
Nombre: alert-critical-issues Trigger: Cuando severity es P1 o P2
**Prompt:** ```markdown Analiza el problema detectado y proporciona contexto. ## Problema detectado: ${HEALTH_CHECK_RESULT} ## Análisis a realizar: 1. **Correlación temporal** - ¿Hubo deployment reciente? - ¿Cambios de configuración? - ¿Patrones similares antes? 2. **Análisis de logs** - Busca errores en los últimos 15 minutos - Identifica stack traces - Encuentra patrones de error 3. **Métricas del sistema** - CPU, memoria, disco - Conexiones de red - Latencia de BD 4. **Impacto** - Usuarios afectados estimados - Funcionalidades impactadas - Severidad (P1/P2/P3/P4) ## Output esperado: ```json { "severity": "P1|P2|P3|P4", "summary": "Descripción corta del problema", "root_cause_hypothesis": "Hipótesis de causa raíz", "affected_services": ["lista"], "affected_users_estimate": number, "recommended_actions": ["acción 1", "acción 2"], "related_incidents": ["INC-123"], "evidence": { "logs": ["extractos relevantes"], "metrics": {"key": "value"} } }**Prompt:** ```markdown Envía alerta crítica con toda la información relevante. ## Datos del incidente: ${ANALYSIS_RESULT} ## Acciones: 1. Envía mensaje a Slack #incidents con: - Emoji de severidad (🔴 P1, 🟠 P2) - Resumen del problema - Servicios afectados - Acciones recomendadas - Link al dashboard 2. Envía SMS a oncall si P1 3. Crea issue en backlog con: - Toda la información del análisis - Labels: incidente, severidad - Prioridad: Crítica 4. Actualiza status page si aplica
Resumen de problemas menores (P3/P4)¶
Prompt:
Resume los problemas menores de la última hora.
## Recopila:
- Todos los issues P3/P4 sin resolver
- Agrupa por tipo de problema
- Identifica patrones
## Si hay problemas:
1. Envía resumen a Slack #ops con:
- Cantidad de issues por tipo
- Tendencia (mejorando/empeorando)
- Acción recomendada si hay patrón
## Si no hay problemas:
- No envíes nada (evitar spam)
Paso 4: Dashboard de estado¶
Crea una tarea que actualice un dashboard:
Prompt:
Actualiza el dashboard de estado en tiempo real.
## Datos a mostrar:
- Estado general del sistema
- Uptime de cada servicio (últimas 24h)
- Incidentes activos
- Próximos mantenimientos
## Formato de actualización:
Actualiza el archivo status.json en S3 con la información actual.
Paso 5: Reportes de incidentes¶
Cuando se resuelve un incidente:
Prompt:
Genera un reporte post-mortem del incidente.
## Incidente: ${ISSUE_ID}
## Secciones del reporte:
1. **Resumen ejecutivo**
- Qué pasó
- Impacto
- Duración
2. **Timeline**
- Hora de inicio
- Detección
- Respuesta
- Mitigación
- Resolución
3. **Análisis de causa raíz**
- Causa técnica
- Por qué no se previno
- Factores contribuyentes
4. **Impacto**
- Usuarios afectados
- Transacciones perdidas
- SLA impactado
5. **Acciones correctivas**
- Inmediatas (ya tomadas)
- A corto plazo (esta semana)
- A largo plazo (este mes)
6. **Lecciones aprendidas**
- Qué funcionó bien
- Qué mejorar
## Output:
Genera documento en formato Markdown y guárdalo en el proyecto.
Verificación¶
Tu sistema de monitoreo está completo si:
- [ ] Health checks se ejecutan cada 5 minutos
- [ ] Problemas críticos generan alertas inmediatas
- [ ] Problemas menores se resumen cada hora
- [ ] Se crean issues automáticamente
- [ ] Dashboard se actualiza en tiempo real
Métricas del sistema de monitoreo¶
Monitorea tu propio sistema de monitoreo:
- Tiempo medio de detección (MTTD)
- Tiempo medio de notificación
- Falsos positivos por semana
- Incidentes auto-detectados vs reportados
Buenas prácticas¶
Evita fatiga de alertas
Solo alerta lo que requiere acción inmediata. Agrupa el resto.
Contexto en alertas
Incluye siempre qué hacer, no solo qué pasó.
Revisa regularmente
Ajusta umbrales según aprendas del sistema.
Has completado todas las guías. ¡Tu sistema Nexus está listo para producción!