Lab : Implementação do Monitoramento

Objetivo

Configurar um sistema de monitoramento completo com métricas, alarmes, logs e dashboard.

Parte 1 : Alarmes Básicos

Exercício 1.1 : Alarme de CPU

Crie um alarme que dispare quando a CPU ultrapassar 80% por 10 minutos:

# Complete o comando
aws cloudwatch put-metric-alarm \
    --alarm-name _____ \
    --metric-name _____ \
    --namespace _____ \
    --statistic _____ \
    --period _____ \
    --threshold _____ \
    --comparison-operator _____ \
    --evaluation-periods _____ \
    --dimensions Name=InstanceId,Value=i-xxx \
    --alarm-actions arn:aws:sns:...:alerts

💡 Solução

aws cloudwatch put-metric-alarm \
    --alarm-name ec2-cpu-high \
    --metric-name CPUUtilization \
    --namespace AWS/EC2 \
    --statistic Average \
    --period 300 \
    --threshold 80 \
    --comparison-operator GreaterThanThreshold \
    --evaluation-periods 2 \
    --dimensions Name=InstanceId,Value=i-xxx \
    --alarm-actions arn:aws:sns:us-east-1:123456789:alerts \
    --alarm-description "CPU acima de 80% por 10 minutos"

Explicação:

Período 300s × 2 avaliações = 10 minutos
Média para evitar falsos positivos de picos curtos

Exercício 1.2 : Alarme de Disco

Crie um alarme para espaço em disco baixo (> 85% utilizado):

Parâmetro	Valor
Metric Name	?
Namespace	?
Threshold	?
Period	?

💡 Solução

Parâmetro	Valor
Metric Name	disk_used_percent
Namespace	CWAgent
Threshold	85
Period	3600 (1 hora)

Nota: Esta métrica requer o CloudWatch Agent instalado na instância.

Parte 2 : Configuração de Logs

Exercício 2.1 : Log Group e Retenção

# Criar um log group com retenção de 30 dias
aws logs create-log-group \
    --log-group-name /app/web-server

aws logs put-retention-policy \
    --log-group-name /app/web-server \
    --retention-in-days _____

💡 Solução

aws logs put-retention-policy \
    --log-group-name /app/web-server \
    --retention-in-days 30

Valores possíveis: 1, 3, 5, 7, 14, 30, 60, 90, 120, 150, 180, 365, 400, 545, 731, 1096, 1827, 2192, 2557, 2922, 3288, 3653

Exercício 2.2 : Metric Filter

Crie um filtro para contar erros 500 nos logs:

aws logs put-metric-filter \
    --log-group-name /app/web-server \
    --filter-name error-500-count \
    --filter-pattern '_______________' \
    --metric-transformations \
        metricName=Error500Count,\
        metricNamespace=WebApp,\
        metricValue=1

💡 Solução

aws logs put-metric-filter \
    --log-group-name /app/web-server \
    --filter-name error-500-count \
    --filter-pattern '"HTTP/1.1" 500' \
    --metric-transformations \
        metricName=Error500Count,\
        metricNamespace=WebApp,\
        metricValue=1

# Ou para logs JSON
aws logs put-metric-filter \
    --log-group-name /app/web-server \
    --filter-name error-500-json \
    --filter-pattern '{ $.statusCode = 500 }' \
    --metric-transformations \
        metricName=Error500Count,\
        metricNamespace=WebApp,\
        metricValue=1

Parte 3 : Log Insights Queries

Exercício 3.1 : Consultas de Análise

Escreva as consultas do Log Insights para:

A. Os 10 últimos erros:

# Sua consulta aqui

B. Número de erros por hora nas últimas 24h:

# Sua consulta aqui

C. Top 5 páginas com erro 404:

# Sua consulta aqui

💡 Soluções

A. Os 10 últimos erros:

fields @timestamp, @message
| filter @message like /ERROR|Exception|error/
| sort @timestamp desc
| limit 10

B. Número de erros por hora nas últimas 24h:

fields @timestamp, @message
| filter @message like /ERROR/
| stats count() as error_count by bin(1h)
| sort @timestamp desc

C. Top 5 páginas com erro 404:

fields @timestamp, @message
| filter @message like /404/
| parse @message /GET (?<path>\/[^ ]*)/
| stats count() as hits by path
| sort hits desc
| limit 5

Parte 4 : Dashboard

Exercício 4.1 : Criar um Dashboard

Defina os widgets para um dashboard de produção:

Widget	Tipo	Métrica	Período
CPU Overview	?	?	?
Memory Usage	?	?	?
Request Count	?	?	?
Error Rate	?	?	?
Latency P99	?	?	?
Alarm Status	?	?	?

💡 Solução

Widget	Tipo	Métrica	Período
CPU Overview	Linha	CPUUtilization	5 min
Memory Usage	Linha	mem_used_percent	5 min
Request Count	Área Empilhada	RequestCount	1 min
Error Rate	Número	HTTPCode_5XX / Total × 100	5 min
Latency P99	Linha	TargetResponseTime p99	1 min
Alarm Status	Status de Alarme	Todos os alarmes	-

Exercício 4.2 : Dashboard JSON

{
    "widgets": [
        {
            "type": "metric",
            "properties": {
                "title": "CPU Utilization",
                "metrics": [
                    ["AWS/EC2", "CPUUtilization", "InstanceId", "i-xxx"]
                ],
                "period": 300,
                "stat": "Average",
                "region": "us-east-1"
            }
        },
        {
            "type": "___",
            "properties": {
                "title": "Alarm Status",
                "alarms": [
                    "arn:aws:cloudwatch:...:alarm:cpu-high",
                    "arn:aws:cloudwatch:...:alarm:mem-high"
                ]
            }
        }
    ]
}

💡 Solução

{
    "widgets": [
        {
            "type": "metric",
            "x": 0, "y": 0, "width": 12, "height": 6,
            "properties": {
                "title": "CPU Utilization",
                "metrics": [
                    ["AWS/EC2", "CPUUtilization", "InstanceId", "i-xxx"]
                ],
                "period": 300,
                "stat": "Average",
                "region": "us-east-1",
                "view": "timeSeries"
            }
        },
        {
            "type": "alarm",
            "x": 12, "y": 0, "width": 12, "height": 6,
            "properties": {
                "title": "Alarm Status",
                "alarms": [
                    "arn:aws:cloudwatch:us-east-1:123456789:alarm:cpu-high",
                    "arn:aws:cloudwatch:us-east-1:123456789:alarm:mem-high"
                ]
            }
        }
    ]
}

Parte 5 : Runbook

Exercício 5.1 : Criar um Runbook

Complete o runbook para o incidente "Memória Alta":

┌─────────────────────────────────────────────────────────────┐
│   RUNBOOK : MEMÓRIA ALTA (> 90%)                            │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│   AVALIAÇÃO INICIAL (máx 2 min)                             │
│   ☐ _______________________________________                 │
│   ☐ _______________________________________                 │
│                                                              │
│   DIAGNÓSTICO (máx 5 min)                                   │
│   ☐ _______________________________________                 │
│   ☐ _______________________________________                 │
│   ☐ _______________________________________                 │
│                                                              │
│   AÇÕES DE REMEDIAÇÃO                                       │
│   ☐ _______________________________________                 │
│   ☐ _______________________________________                 │
│                                                              │
│   VALIDAÇÃO                                                 │
│   ☐ _______________________________________                 │
│   ☐ _______________________________________                 │
│                                                              │
└─────────────────────────────────────────────────────────────┘

💡 Solução

┌─────────────────────────────────────────────────────────────┐
│   RUNBOOK : MEMÓRIA ALTA (> 90%)                            │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│   AVALIAÇÃO INICIAL (máx 2 min)                             │
│   ☐ Verificar se várias instâncias estão afetadas           │
│   ☐ Verificar erros de usuário (502, timeouts)              │
│                                                              │
│   DIAGNÓSTICO (máx 5 min)                                   │
│   ☐ Conexão SSH: free -h, top -o %MEM                       │
│   ☐ Identificar o processo que consome mais memória         │
│   ☐ Verificar logs do aplicativo para vazamentos de memória │
│                                                              │
│   AÇÕES DE REMEDIAÇÃO                                       │
│   ☐ Se vazamento de memória: Reiniciar a aplicação          │
│   ☐ Se carga legítima: Scale out (adicionar instâncias)     │
│   ☐ Liberar cache se possível (drop_caches)                 │
│                                                              │
│   VALIDAÇÃO                                                 │
│   ☐ Memória voltou para < 80%?                              │
│   ☐ Aplicação está funcionando normalmente?                 │
│   ☐ Criar ticket para análise post-mortem                   │
│                                                              │
└─────────────────────────────────────────────────────────────┘

Parte 6 : Cenário Completo

Contexto

Você recebe um alerta: "Error rate above 5% for web-app"

Perguntas

Quais métricas você consulta primeiro?
Quais logs você analisa?
Qual consulta do Log Insights você utiliza?
Como identificar a causa raiz?

💡 Solução Detalhada

1. Métricas a consultar:

HTTPCode_Target_5XX (ALB) → Confirmar erros 500
RequestCount → Volume de tráfego
TargetResponseTime → Latência
HealthyHostCount → Instâncias fora do ar?
CPUUtilization, Memory → Recursos saturados?

2. Logs a analisar:

/aws/elasticloadbalancing/ → Logs do ALB
/app/web-server → Logs do aplicativo
/var/log/messages → Logs do sistema

3. Consulta Log Insights:

fields @timestamp, @message
| filter @message like /500|ERROR|Exception/
| stats count() by bin(5m)
| sort @timestamp desc

Depois para detalhar:

fields @timestamp, @message
| filter @message like /500/
| parse @message /(?<endpoint>\/api\/[^ ]*)/
| stats count() by endpoint
| sort count desc
| limit 10

4. Processo de identificação:

Correlacionar o horário do pico de erros com os deploys
Identificar o endpoint problemático
Verificar os logs desse endpoint específico
Procurar a stack trace do erro
Identificar a causa (timeout no banco, bug de código, configuração...)

Entregável

Documento a Produzir

Configuração dos alarmes (comandos CLI)
Consultas Log Insights (mínimo 3)
Definição do Dashboard (JSON ou descrição)
Runbook completo para 2 cenários
Análise do cenário com solução

Critérios de Avaliação

Critério	Pontos
Alarmes corretamente configurados	/20
Consultas Log Insights	/20
Dashboard relevante	/20
Runbooks completos	/25
Análise do cenário	/15
Total	/100

Semana seguinte: MODULE 14 - FinOps

Objetivo​

Parte 1 : Alarmes Básicos​

Exercício 1.1 : Alarme de CPU​

Exercício 1.2 : Alarme de Disco​

Parte 2 : Configuração de Logs​

Exercício 2.1 : Log Group e Retenção​

Exercício 2.2 : Metric Filter​

Parte 3 : Log Insights Queries​

Exercício 3.1 : Consultas de Análise​

Parte 4 : Dashboard​

Exercício 4.1 : Criar um Dashboard​

Exercício 4.2 : Dashboard JSON​

Parte 5 : Runbook​

Exercício 5.1 : Criar um Runbook​

Parte 6 : Cenário Completo​

Contexto​

Perguntas​

Entregável​

Documento a Produzir​

Critérios de Avaliação​

Objetivo

Parte 1 : Alarmes Básicos

Exercício 1.1 : Alarme de CPU

Exercício 1.2 : Alarme de Disco

Parte 2 : Configuração de Logs

Exercício 2.1 : Log Group e Retenção

Exercício 2.2 : Metric Filter

Parte 3 : Log Insights Queries

Exercício 3.1 : Consultas de Análise

Parte 4 : Dashboard

Exercício 4.1 : Criar um Dashboard

Exercício 4.2 : Dashboard JSON

Parte 5 : Runbook

Exercício 5.1 : Criar um Runbook

Parte 6 : Cenário Completo

Contexto

Perguntas

Entregável

Documento a Produzir

Critérios de Avaliação