Configuracion de Monitoreo y Alertas

El Problema

Te enteras que tu app esta caida cuando un cliente te envia un email — o peor, tuitea al respecto. Sin monitoreo, estas ciego ante rendimiento degradado, memory leaks progresivos, agotamiento del pool de conexiones a base de datos y picos de tasa de error que preceden caidas totales. Cuando los usuarios lo notan, el daño ya esta hecho. Necesitas un sistema que te alerte minutos antes del impacto en usuarios, no horas despues.

El Prompt

Eres un arquitecto de monitoreo y observabilidad. Diseña una estrategia de monitoreo para mi aplicacion.

DETALLES DE LA APLICACION:
- Stack: [ej., Node.js/Express, Python/FastAPI, Go/Gin]
- Infraestructura: [ej., AWS ECS, Kubernetes, Vercel, bare metal]
- Base de datos: [ej., PostgreSQL, MongoDB, Redis]
- Monitoreo actual: [ej., ninguno, chequeo basico de uptime, Datadog, Prometheus]
- Tamaño del equipo: [ej., solo, 3-5, 10+]
- Presupuesto: [ej., solo free tier, $50/mes, enterprise]

Diseña un sistema de monitoreo que cubra:
1. **Las cuatro señales doradas**: Como medir latencia, trafico, errores y saturacion para mi stack especifico.
2. **Diseño del dashboard**: Que paneles mostrar en el dashboard principal, organizados por prioridad.
3. **Reglas de alertas**: Define alertas con umbrales especificos, niveles de severidad y rutas de escalacion.
4. **Higiene de alertas**: Como prevenir fatiga de alertas — cuales alertas paginan vs. crean tickets vs. son informativas.
5. **Seleccion de herramientas**: Recomienda herramientas especificas para mi presupuesto y tamaño de equipo.
6. **Definicion de SLI/SLO**: Define Service Level Indicators y Objectives para mis endpoints mas criticos.
7. **Guia de configuracion**: Implementacion paso a paso para mi stack de herramientas recomendado.

Ejemplo de Salida

Señales doradas (Node.js/Express + PostgreSQL):
- Latencia: p50, p95, p99 de tiempo de respuesta por endpoint (objetivo: p99 < 500ms)
- Trafico: requests/segundo por endpoint y codigo de estado
- Errores: tasa de 5xx como porcentaje del total de solicitudes (objetivo: < 0.1%)
- Saturacion: CPU %, memoria %, uso del pool de conexiones DB %, event loop lag

Reglas de alertas:
- CRITICO (paginar): Tasa de error > 1% por 5 min, latencia p99 > 2s por 5 min
- ADVERTENCIA (ticket): Tasa de error > 0.5% por 15 min, memoria > 85% por 10 min
- INFO (dashboard): Deploy completado, actualizacion de dependencia disponible

Cuando Usarlo

Usa este skill al lanzar un nuevo servicio a produccion, despues de una caida donde no tenias visibilidad, o cuando la fatiga de alertas ha hecho que tu equipo ignore las notificaciones. Revisalo trimestralmente para ajustar umbrales basados en patrones de trafico reales.

Consejos Pro

• Alerta sobre sintomas, no causas — alerta cuando la tasa de error sube (sintoma), no cuando el CPU alcanza 80% (causa). CPU alto que no afecta usuarios no justifica despertar a alguien.
• Cada alerta debe tener un runbook — si alguien es paginado a las 3 AM, necesita un enlace a un documento que diga exactamente que revisar y como mitigar.
• Usa error budgets en vez de tolerancia cero — un SLO de 99.9% significa que aceptas 43 minutos de inactividad al mes. Esto previene sobre-alertar por parpadeos breves que se resuelven solos.
• La jerarquia del dashboard importa — el dashboard principal debe responder “esta todo bien?” en 3 segundos. Los dashboards de detalle responden “que especificamente esta roto?”