Alarmes e Alertas CloudWatch
Introdução
Os alarmes do CloudWatch monitoram suas métricas e disparam ações automáticas quando limites são atingidos. É um componente essencial para observabilidade e resposta operacional.
Arquitetura dos Alarmes
┌─────────────────────────────────────────────────────────────────┐
│ FLUXO DOS ALARMES │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────────┐ │
│ │ Métrica │────►│ Alarme │────►│ Ações │ │
│ │ │ │ │ │ │ │
│ │ CPU 85% │ │ Limite>80%│ │ • SNS (email/SMS) │ │
│ └──────────┘ └──────────┘ │ • Auto Scaling │ │
│ │ • Lambda │ │
│ │ • EC2 (stop/reboot) │ │
│ └──────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Estados de um Alarme
┌─────────────────────────────────────────────────────────────────┐
│ ESTADOS DO ALARME │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ │
│ │ OK │ Métrica dentro dos limites normais │
│ │ (Verde) │ │
│ └────────┬────────┘ │
│ │ │
│ ▼ Limite ultrapassado │
│ ┌─────────────────┐ │
│ │ ALARM │ Limite atingido → Ações disparadas │
│ │ (Vermelho) │ │
│ └────────┬────────┘ │
│ │ │
│ ▼ Dados insuficientes │
│ ┌─────────────────┐ │
│ │ INSUFFICIENT │ Dados insuficientes para avaliar │
│ │ DATA │ │
│ │ (Cinza) │ │
│ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Configuração de um Alarme
Elementos de Configuração
┌─────────────────────────────────────────────────────────────────┐
│ ANATOMIA DE UM ALARME │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. MÉTRICA │
│ └── Qual métrica monitorar? │
│ Ex: CPUUtilization, NetworkIn, Errors │
│ │
│ 2. ESTATÍSTICA │
│ └── Como agregar os dados? │
│ Average, Sum, Minimum, Maximum, SampleCount │
│ │
│ 3. PERÍODO │
│ └── Janela de tempo para cada ponto │
│ 60s, 300s (5min), 3600s (1h) │
│ │
│ 4. LIMITE │
│ └── Qual valor dispara o alarme? │
│ > 80%, < 10, >= 1000 │
│ │
│ 5. PERÍODOS DE AVALIAÇÃO │
│ └── Quantos períodos em violação? │
│ "3 de 5 períodos" (evita falsos positivos) │
│ │
│ 6. AÇÕES │
│ └── O que fazer quando o alarme dispara? │
│ Notificação, Auto Scaling, etc. │
│ │
└─────────────────────────────────────────────────────────────────┘
Exemplo: Alarme de CPU EC2
# Pseudo-configuration CloudFormation
HighCPUAlarm:
Type: AWS::CloudWatch::Alarm
Properties:
AlarmName: "EC2-HighCPU-Production"
AlarmDescription: "CPU superior a 80% por 5 minutos"
# Métrica
Namespace: "AWS/EC2"
MetricName: "CPUUtilization"
Dimensions:
- Name: InstanceId
Value: "i-1234567890abcdef0"
# Avaliação
Statistic: "Average"
Period: 60 # 1 minuto
EvaluationPeriods: 5 # 5 períodos
DatapointsToAlarm: 3 # 3 de 5 em violação
# Limite
ComparisonOperator: "GreaterThanThreshold"
Threshold: 80
# Ações
AlarmActions:
- "arn:aws:sns:us-east-1:123456789:AlerteOps"
OKActions:
- "arn:aws:sns:us-east-1:123456789:AlerteOps"
Tipos Comuns de Alarmes
1. Alarmes de Performance
| Serviço | Métrica | Limite típico | Motivo |
|---|---|---|---|
| EC2 | CPUUtilization | > 80% | Sobrecarga |
| EC2 | StatusCheckFailed | > 0 | Instância com falha |
| RDS | DatabaseConnections | > 80% máx | Saturação |
| ELB | TargetResponseTime | > 2s | Latência |
| Lambda | Duration | > 80% timeout | Risco de timeout |
2. Alarmes de Erros
| Serviço | Métrica | Limite típico | Motivo |
|---|---|---|---|
| Lambda | Errors | > 1% | Taxa de erro |
| ALB | HTTPCode_Target_5XX | > 10 | Erros de servidor |
| API Gateway | 4XXError | > 5% | Erros de cliente |
| SQS | ApproximateNumberOfMessagesVisible | > 1000 | Fila saturada |
3. Alarmes de Custos
| Métrica | Limite | Ação |
|---|---|---|
| EstimatedCharges | > Orçamento | Notificação |
| EC2 Running Hours | > Previsto | Investigação |
Alarmes Compostos
┌─────────────────────────────────────────────────────────────────┐
│ ALARME COMPOSTO │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Combina vários alarmes com lógica AND/OR/NOT │
│ │
│ Exemplo: Alerta crítico somente se: │
│ - CPU > 80% E │
│ - Memória > 90% E │
│ - NÃO está em manutenção │
│ │
│ ┌────────────┐ │
│ │ CPU > 80% │───┐ │
│ └────────────┘ │ │
│ │ AND │
│ ┌────────────┐ ├────────► ALARME COMPOSTO │
│ │ Mem > 90% │───┤ │ │
│ └────────────┘ │ ▼ │
│ │ Ações críticas │
│ ┌────────────┐ │ │
│ │NOT Maint. │───┘ │
│ └────────────┘ │
│ │
│ Vantagem: Reduz falsos positivos │
│ │
└─────────────────────────────────────────────────────────────────┘
Ações Automáticas
SNS (Notificações)
┌─────────────────────────────────────────────────────────────────┐
│ NOTIFICAÇÕES SNS │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Alarme ────► SNS Topic ────► Assinantes │
│ │ │
│ ├──► Email (equipe-ops@company.com) │
│ ├──► SMS (+1-555-123-4567) │
│ ├──► Slack (webhook) │
│ ├──► PagerDuty (integração) │
│ └──► Lambda (automação) │
│ │
└─────────────────────────────────────────────────────────────────┘
Auto Scaling
Alarme CPU > 80% ────► Ação: Scale Out (+2 instâncias)
Alarme CPU < 30% ────► Ação: Scale In (-1 instância)
Ações EC2
Alarme StatusCheck Failed ────► Ação: Recuperar Instância
Alarme Instance Idle ────► Ação: Parar Instância
Boas Práticas
1. Evitar Falsos Positivos
# RUIM: Alarme muito sensível
Period: 60
EvaluationPeriods: 1
DatapointsToAlarm: 1
# → Dispara a cada pico
# BOM: Alarme com tolerância
Period: 60
EvaluationPeriods: 5
DatapointsToAlarm: 3
# → 3 violações em 5 minutos = problema real
2. Nomenclatura Clara
Formato recomendado:
[Ambiente]-[Serviço]-[Métrica]-[Severidade]
Exemplos:
• PROD-EC2-HighCPU-Critical
• PROD-Lambda-Errors-Warning
• DEV-RDS-Connections-Info
3. Documentação dos Alarmes
Cada alarme deve ter:
• Descrição clara
• Runbook associado (o que fazer quando disparar)
• Responsável (quem é o dono)
• Histórico de disparos
Exemplo de Configuração Completa
Monitoramento de uma Aplicação Web
┌─────────────────────────────────────────────────────────────────┐
│ ALARMES PARA APLICAÇÃO WEB │
├─────────────────────────────────────────────────────────────────┤
│ │
│ CAMADA DE APRESENTAÇÃO (ALB) │
│ ├── ALB-HighLatency (ResponseTime > 2s) │
│ ├── ALB-High5XX (5XX > 10/min) │
│ └── ALB-UnhealthyHosts (> 0) │
│ │
│ CAMADA DE APLICAÇÃO (EC2/Lambda) │
│ ├── EC2-HighCPU (> 80%) │
│ ├── EC2-HighMemory (> 85%) │
│ ├── Lambda-HighErrors (> 1%) │
│ └── Lambda-NearTimeout (> 80% timeout) │
│ │
│ CAMADA DE DADOS (RDS) │
│ ├── RDS-HighCPU (> 80%) │
│ ├── RDS-LowStorage (< 20%) │
│ ├── RDS-HighConnections (> 80% máx) │
│ └── RDS-ReplicaLag (> 60s) │
│ │
│ CUSTOS │
│ └── Billing-OverBudget (> orçamento mensal) │
│ │
└─────────────────────────────────────────────────────────────────┘
Exercício: Criar um Plano de Alarmes
Para uma aplicação de e-commerce, defina os alarmes para:
- Disponibilidade: A aplicação está acessível
- Performance: Tempo de resposta aceitável
- Erros: Baixa taxa de erro
- Capacidade: Recursos suficientes
Ver a solução
| Categoria | Alarme | Métrica | Limite | Ação |
|---|---|---|---|---|
| Disponibilidade | ALB-NoHealthyTargets | HealthyHostCount | = 0 | PagerDuty Critical |
| Disponibilidade | Route53-HealthCheck | HealthCheckStatus | Failed | SNS + Failover |
| Performance | ALB-HighLatency | TargetResponseTime | > 3s | SNS Warning |
| Performance | Lambda-SlowExecution | Duration | > 10s | SNS Warning |
| Erros | ALB-High5XX | HTTPCode_Target_5XX | > 50/5min | SNS Critical |
| Erros | Lambda-HighErrors | Errors | > 5% | SNS Critical |
| Capacidade | EC2-HighCPU | CPUUtilization | > 80% | Auto Scaling |
| Capacidade | RDS-LowStorage | FreeStorageSpace | < 10GB | SNS Warning |
Resumo
- Alarmes monitoram métricas e disparam ações
- 3 estados: OK, ALARM, INSUFFICIENT_DATA
- Configure períodos de avaliação para evitar falsos positivos
- Use alarmes compostos para condições complexas
- Documente cada alarme com um runbook
Próxima seção: Quiz de Validação