Alarmas y Alertas CloudWatch
Introducción
Las alarmas de CloudWatch supervisan sus métricas y desencadenan acciones automáticas cuando se alcanzan ciertos umbrales. Es un componente esencial de la observabilidad y la capacidad de respuesta operativa.
Arquitectura de las Alarmas
┌─────────────────────────────────────────────────────────────────┐
│ FLUJO DE LAS ALARMAS │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────────┐ │
│ │ Métrica │────►│ Alarma │────►│ Acciones │ │
│ │ │ │ │ │ │ │
│ │ CPU 85% │ │ Umbral>80%│ │ • SNS (email/SMS) │ │
│ └──────────┘ └──────────┘ │ • Auto Scaling │ │
│ │ • Lambda │ │
│ │ • EC2 (stop/reboot) │ │
│ └──────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Estados de una Alarma
┌─────────────────────────────────────────────────────────────────┐
│ ESTADOS DE ALARMA │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ │
│ │ OK │ Métrica dentro de los límites normales │
│ │ (Verde) │ │
│ └────────┬────────┘ │
│ │ │
│ ▼ Umbral superado │
│ ┌─────────────────┐ │
│ │ ALARM │ Umbral alcanzado → Acciones ejecutadas │
│ │ (Rojo) │ │
│ └────────┬────────┘ │
│ │ │
│ ▼ Datos faltantes │
│ ┌─────────────────┐ │
│ │ INSUFFICIENT │ No hay suficientes datos para evaluar │
│ │ DATA │ │
│ │ (Gris) │ │
│ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Configuración de una Alarma
Elementos de Configuración
┌─────────────────────────────────────────────────────────────────┐
│ ANATOMÍA DE UNA ALARMA │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. MÉTRICA │
│ └── ¿Qué métrica supervisar? │
│ Ej: CPUUtilization, NetworkIn, Errors │
│ │
│ 2. ESTADÍSTICA │
│ └── ¿Cómo agregar los datos? │
│ Average, Sum, Minimum, Maximum, SampleCount │
│ │
│ 3. PERIODO │
│ └── Ventana de tiempo para cada punto │
│ 60s, 300s (5min), 3600s (1h) │
│ │
│ 4. UMBRAL │
│ └── ¿Qué valor dispara la alarma? │
│ > 80%, < 10, >= 1000 │
│ │
│ 5. PERIODOS DE EVALUACIÓN │
│ └── ¿Cuántos periodos en violación? │
│ "3 de 5 periodos" (evita falsos positivos) │
│ │
│ 6. ACCIONES │
│ └── ¿Qué hacer cuando se dispara la alarma? │
│ Notificación, Auto Scaling, etc. │
│ │
└─────────────────────────────────────────────────────────────────┘
Ejemplo: Alarma CPU EC2
# Pseudo-configuration CloudFormation
HighCPUAlarm:
Type: AWS::CloudWatch::Alarm
Properties:
AlarmName: "EC2-HighCPU-Production"
AlarmDescription: "CPU superieur a 80% pendant 5 minutes"
# Metrique
Namespace: "AWS/EC2"
MetricName: "CPUUtilization"
Dimensions:
- Name: InstanceId
Value: "i-1234567890abcdef0"
# Evaluation
Statistic: "Average"
Period: 60 # 1 minute
EvaluationPeriods: 5 # 5 periodes
DatapointsToAlarm: 3 # 3 sur 5 en violation
# Seuil
ComparisonOperator: "GreaterThanThreshold"
Threshold: 80
# Actions
AlarmActions:
- "arn:aws:sns:us-east-1:123456789:AlerteOps"
OKActions:
- "arn:aws:sns:us-east-1:123456789:AlerteOps"
Tipos de Alarmas Comunes
1. Alarmas de Rendimiento
| Servicio | Métrica | Umbral típico | Motivo |
|---|---|---|---|
| EC2 | CPUUtilization | > 80% | Sobrecarga |
| EC2 | StatusCheckFailed | > 0 | Instancia defectuosa |
| RDS | DatabaseConnections | > 80% máx | Saturación |
| ELB | TargetResponseTime | > 2s | Latencia |
| Lambda | Duration | > 80% timeout | Riesgo de timeout |
2. Alarmas de Errores
| Servicio | Métrica | Umbral típico | Motivo |
|---|---|---|---|
| Lambda | Errors | > 1% | Tasa de error |
| ALB | HTTPCode_Target_5XX | > 10 | Errores de servidor |
| API Gateway | 4XXError | > 5% | Errores de cliente |
| SQS | ApproximateNumberOfMessagesVisible | > 1000 | Cola saturada |
3. Alarmas de Costos
| Métrica | Umbral | Acción |
|---|---|---|
| EstimatedCharges | > Presupuesto | Notificación |
| EC2 Running Hours | > Previsto | Investigación |
Alarmas Compuestas
┌─────────────────────────────────────────────────────────────────┐
│ ALARMA COMPUESTA │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Combina varias alarmas con lógica AND/OR/NOT │
│ │
│ Ejemplo: Alerta crítica solo si: │
│ - CPU > 80% Y │
│ - Memoria > 90% Y │
│ - NO está en mantenimiento │
│ │
│ ┌────────────┐ │
│ │ CPU > 80% │───┐ │
│ └────────────┘ │ │
│ │ AND │
│ ┌────────────┐ ├────────► ALARMA COMPUESTA │
│ │ Mem > 90% │───┤ │ │
│ └────────────┘ │ ▼ │
│ │ Acciones críticas │
│ ┌────────────┐ │ │
│ │NOT Maint. │───┘ │
│ └────────────┘ │
│ │
│ Ventaja: Reduce los falsos positivos │
│ │
└─────────────────────────────────────────────────────────────────┘
Acciones Automáticas
SNS (Notificaciones)
┌─────────────────────────────────────────────────────────────────┐
│ NOTIFICACIONES SNS │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Alarma ────► SNS Topic ────► Suscriptores │
│ │ │
│ ├──► Email (equipo-ops@company.com) │
│ ├──► SMS (+1-555-123-4567) │
│ ├──► Slack (webhook) │
│ ├──► PagerDuty (integración) │
│ └──► Lambda (automatización) │
│ │
└─────────────────────────────────────────────────────────────────┘
Auto Scaling
Alarma CPU > 80% ────► Acción: Scale Out (+2 instancias)
Alarma CPU < 30% ────► Acción: Scale In (-1 instancia)
Acciones EC2
Alarma StatusCheck Failed ────► Acción: Recuperar Instancia
Alarma Instance Idle ────► Acción: Detener Instancia
Buenas Prácticas
1. Evitar Falsos Positivos
# MALO: Alarma demasiado sensible
Period: 60
EvaluationPeriods: 1
DatapointsToAlarm: 1
# → Se dispara ante cualquier pico
# BUENO: Alarma con tolerancia
Period: 60
EvaluationPeriods: 5
DatapointsToAlarm: 3
# → 3 violaciones en 5 minutos = problema real
2. Nomenclatura Clara
Formato recomendado:
[Ambiente]-[Servicio]-[Métrica]-[Severidad]
Ejemplos:
• PROD-EC2-HighCPU-Critical
• PROD-Lambda-Errors-Warning
• DEV-RDS-Connections-Info
3. Documentación de las Alarmas
Cada alarma debe tener:
• Descripción clara
• Runbook asociado (qué hacer cuando se dispara)
• Responsable (quién es responsable)
• Historial de activaciones
Ejemplo de Configuración Completa
Supervisión de una Aplicación Web
┌─────────────────────────────────────────────────────────────────┐
│ ALARMAS PARA APLICACIÓN WEB │
├─────────────────────────────────────────────────────────────────┤
│ │
│ CAPA DE PRESENTACIÓN (ALB) │
│ ├── ALB-HighLatency (ResponseTime > 2s) │
│ ├── ALB-High5XX (5XX > 10/min) │
│ └── ALB-UnhealthyHosts (> 0) │
│ │
│ CAPA DE APLICACIÓN (EC2/Lambda) │
│ ├── EC2-HighCPU (> 80%) │
│ ├── EC2-HighMemory (> 85%) │
│ ├── Lambda-HighErrors (> 1%) │
│ └── Lambda-NearTimeout (> 80% timeout) │
│ │
│ CAPA DE DATOS (RDS) │
│ ├── RDS-HighCPU (> 80%) │
│ ├── RDS-LowStorage (< 20%) │
│ ├── RDS-HighConnections (> 80% máx) │
│ └── RDS-ReplicaLag (> 60s) │
│ │
│ COSTOS │
│ └── Billing-OverBudget (> presupuesto mensual) │
│ │
└─────────────────────────────────────────────────────────────────┘
Ejercicio: Crear un Plan de Alarmas
Para una aplicación de comercio electrónico, defina las alarmas para:
- Disponibilidad: La aplicación es accesible
- Rendimiento: Tiempo de respuesta aceptable
- Errores: Baja tasa de error
- Capacidad: Recursos suficientes
Ver la solución
| Categoría | Alarma | Métrica | Umbral | Acción |
|---|---|---|---|---|
| Disponibilidad | ALB-NoHealthyTargets | HealthyHostCount | = 0 | PagerDuty Critical |
| Disponibilidad | Route53-HealthCheck | HealthCheckStatus | Failed | SNS + Failover |
| Rendimiento | ALB-HighLatency | TargetResponseTime | > 3s | SNS Warning |
| Rendimiento | Lambda-SlowExecution | Duration | > 10s | SNS Warning |
| Errores | ALB-High5XX | HTTPCode_Target_5XX | > 50/5min | SNS Critical |
| Errores | Lambda-HighErrors | Errors | > 5% | SNS Critical |
| Capacidad | EC2-HighCPU | CPUUtilization | > 80% | Auto Scaling |
| Capacidad | RDS-LowStorage | FreeStorageSpace | < 10GB | SNS Warning |
Resumen
- Las alarmas supervisan las métricas y ejecutan acciones
- 3 estados: OK, ALARM, INSUFFICIENT_DATA
- Configure periodos de evaluación para evitar falsos positivos
- Utilice alarmas compuestas para condiciones complejas
- Documente cada alarma con un runbook
Próxima sección: Quiz de Validación