Habilidade de Investigação do AWS CloudWatch

Padrões reutilizáveis para investigar incidentes de produção usando CloudWatch Logs, Métricas e Alarmes. Esses padrões são projetados para serem compostos durante o triagem de incidentes.

Padrão 1: Modelos de Consulta do Logs Insights

Detecção de Pico de Erros

Encontre os principais erros em uma janela de tempo, agrupados por tipo de erro:

fields @timestamp, @message, @logStream
| filter @message like /(?i)(error|exception|fatal|critical)/
| stats count(*) as errorCount by bin(5m), @logStream
| sort errorCount desc
| limit 20

Detalhamento da Latência P99 por Operação

Identifique quais operações estão causando picos de latência:

fields @timestamp, @duration, operation
| filter ispresent(@duration)
| stats avg(@duration) as avgMs,
        pct(@duration, 50) as p50Ms,
        pct(@duration, 95) as p95Ms,
        pct(@duration, 99) as p99Ms,
        count(*) as invocations
  by operation
| sort p99Ms desc
| limit 15

Detecção de Cold Start do Lambda

Quantifique o impacto do cold start durante um incidente:

fields @timestamp, @duration, @initDuration, @memorySize, @maxMemoryUsed
| filter ispresent(@initDuration)
| stats count(*) as coldStarts,
        avg(@initDuration) as avgInitMs,
        max(@initDuration) as maxInitMs,
        avg(@duration) as avgDurationMs
  by bin(5m)
| sort @timestamp desc

Detecção de Out-of-Memory (OOM)

Encontre funções Lambda ou contêineres encerrados por pressão de memória:

fields @timestamp, @message, @logStream, @memorySize, @maxMemoryUsed
| filter @message like /Runtime exited|out of memory|OOMKilled|Cannot allocate memory|MemoryError/
| stats count(*) as oomEvents by @logStream, bin(10m)
| sort oomEvents desc
| limit 10

Para tendências de utilização de memória antes do OOM:

fields @timestamp, @maxMemoryUsed, @memorySize
| filter ispresent(@maxMemoryUsed)
| stats max(@maxMemoryUsed / @memorySize * 100) as peakMemPct,
        avg(@maxMemoryUsed / @memorySize * 100) as avgMemPct
  by bin(5m)
| sort @timestamp desc

Detecção de Timeout

Encontre invocações que atingiram o timeout configurado:

fields @timestamp, @duration, @logStream, @requestId
| filter @message like /Task timed out/ or @duration > 28000
| stats count(*) as timeouts by @logStream, bin(5m)
| sort timeouts desc

Padrão 2: Correlação do Histórico de Alarmes com Eventos de Deploy

Processo

1. Obter o tempo de transição do alarme — anote o timestamp exato em que o alarme entrou no estado ALARM.
2. Consultar o CloudTrail para eventos relacionados a deploys em uma janela de [tempo_alarme - 30min, tempo_alarme]:

# CloudTrail Lake query for deployment events
SELECT eventTime, eventName, userIdentity.arn, requestParameters
FROM <event-data-store-id>
WHERE eventTime > '<alarm_time_minus_30m>'
  AND eventTime < '<alarm_time>'
  AND eventName IN (
    'UpdateFunctionCode', 'UpdateFunctionConfiguration',
    'UpdateService', 'CreateDeployment', 'RegisterTaskDefinition',
    'CreateChangeSet', 'ExecuteChangeSet',
    'StartPipelineExecution', 'PutImage'
  )
ORDER BY eventTime DESC

3. Critérios de correlação — um deploy é "correlacionado" se:

   • Ele tem como alvo o mesmo serviço/recurso do alarme
   • Ele foi concluído nos 15 minutos anteriores à transição do alarme
   • A identidade do deployer corresponde a uma função CI/CD (não um humano aplicando um hotfix)

4. Fortalecendo a correlação:

   • Verifique se o mesmo alarme estava saudável no ciclo de deploy anterior
   • Verifique se não houve outras alterações ambientais (eventos de escalonamento, alterações de configuração) na mesma janela
   • Procure falhas em monitores canário/sintéticos que começaram ao mesmo tempo

Formato de Saída

Deploy Correlation:
  Event: UpdateFunctionCode
  Time: 2024-03-15T14:23:07Z (12 min before alarm)
  Actor: arn:aws:sts::123456789012:assumed-role/github-actions-deploy/session
  Resource: arn:aws:lambda:us-east-1:123456789012:function:payment-processor
  Correlation: STRONG — same resource, CI/CD actor, alarm was OK prior cycle

Padrão 3: Árvore de Decisão para Reduzir o Raio de Impacto

Use esta árvore para delimitar sistematicamente um incidente do mais amplo para o mais específico:

INÍCIO
  |
  v
[1] CONTA — Quais contas mostram o alarme?
  |  - Verifique: Alarmes estão disparando em várias contas?
  |  - Se sim → suspeite de serviço compartilhado (SSO, rede, pipeline de deploy compartilhado)
  |  - Se não → prossiga para Região
  v
[2] REGIÃO — Quais regiões são afetadas?
  |  - Verifique: Mesmo alarme em outras regiões?
  |  - Se multi-região → suspeite de serviço global (IAM, Route53, S3 global)

…