Dashboards de saúde da aplicação

Monitoramento e Solução de Problemas na AWS

John Q. Martin

Principal Consultant

Design do dashboard: hierarquia da informação

Pirâmide de três níveis: topo estreito escuro, meio mais largo em azul-petróleo e base mais larga em verde

"Como um hospital: recepção → enfermaria → especialista"

Topo - Resumo executivo

Saúde geral do sistema
Principais métricas de negócio, SLA, incidentes atuais

Meio - Saúde dos serviços

Taxas de erro, percentis de latência, throughput

Base - Diagnóstico detalhado

Traces, logs, uso de recursos, saúde de dependências

Os quatro sinais de ouro

Os quatro sinais de ouro do monitoramento: latência, tráfego, erros e saturação

Cobrindo estes quatro, você cobre a maioria dos problemas que vai encontrar.

O método RED

RED para serviços orientados a requisições:

Padrão RED mostrando rate, errors e duration para serviços orientados a requisições

Relação com os sinais de ouro:

RED é um subconjunto focado dos quatro sinais de ouro
Feito para serviços que lidam com requisições de usuário
Saturação (4º sinal de ouro) adicionada para monitorar infraestrutura

Use RED como ponto de partida e adicione saturação para diagnóstico mais profundo.

Três fontes de dados

Diagrama de três fontes de dados do dashboard: métricas do CloudWatch, traces do X-Ray e CloudWatch Logs

Widgets de métricas do CloudWatch

Volume de requisições:

["AWS/ApplicationELB",
 "RequestCount",
 {"stat": "Sum"}]

Taxa de erro (metric math):

"metrics": [
  ["AWS/Lambda", "Errors",
   {"stat":"Sum","id":"errors"}],
  [".", "Invocations",
   {"stat":"Sum","id":"invocations"}],
  [{"expression":
    "(errors/invocations)*100",
    "label":"Error Rate %"}]
]

Percentis de tempo de resposta:

["AWS/ApplicationELB",
 "TargetResponseTime",
 {"stat": "p50"}],
["AWS/ApplicationELB",
 "TargetResponseTime",
 {"stat": "p95"}],
["AWS/ApplicationELB",
 "TargetResponseTime",
 {"stat": "p99"}]

Volume de requisições do ALB RequestCount
Taxa de erro usa metric math - errors / invocations x 100
Tempo de resposta como percentis p50, p95, p99

Widgets de X-Ray e logs

Widgets do X-Ray:

Service map - topologia da aplicação com indicadores de saúde
Trace statistics - tempo médio de resposta, taxa de erro, taxa de falhas
Service latency - comparação de tempo de resposta por serviço

Widgets do CloudWatch Logs:

Consulta de erros recentes:

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20

Contagem de erros por tipo:

filter @message like /ERROR/
| stats count(*) as errors
    by errorType
| sort errors desc

Layout completo do dashboard

Layout de dashboard de saúde com widgets de resumo no topo, service map no meio e logs de erro abaixo

Fluxo de troubleshooting de incidentes

Prancheta de triagem de emergência com faixas de prioridade coloridas e um estetoscópio

"Como triagem do PS: estabilizar → diagnosticar → tratar → verificar"

Identificar - indicadores vermelhos/amarelos, picos de erro
Delimitar - quais serviços? quando? piorando?
Correlacionar - erros + latência, tráfego + recursos
Aprofundar - service map → traces → logs
Causa raiz - dependência, BD, memória, config
Corrigir - circuit breaker, escalar, rollback, failover
Verificar - taxa de erro normal, mapa verde, alarmes limpos

Cenário 1: pico repentino de tráfego

Dashboard de monitoramento durante pico de tráfego: linhas em pico, medidores no vermelho, banners de alerta vermelhos

O que você vê no dashboard:

Volume de requisições 10× o normal
Taxa de erro 25%
Latência 3000ms
CPU 95%

Análise: Recursos sobrecarregados pelo surto de tráfego

Ações:

Escalar horizontalmente já
Habilitar auto scaling
Implementar rate limiting
Adicionar cache para aliviar o backend

Cenário 2: gargalo no banco de dados

Dashboard de monitoramento mostrando gargalo no banco de dados: ícone de BD vermelho rachado, medidores de CPU e conexões no máximo, latência de consulta subindo forte, pool quase cheio

O que você vê no dashboard:

CPU do BD 95%
Conexões do BD 95/100
Latência de consultas 5000ms
Latência do app 5500ms

Análise: Banco é o gargalo; consultas lentas esgotando o pool de conexões

Ações:

Identificar consultas lentas nos logs
Adicionar índices, otimizar consultas
Aumentar o tamanho do pool de conexões
Escalar o banco de dados

Cenário 3: falha em cascata

O que você vê no service map:

Cascata no service map: nó A âmbar com erros de cliente, B e C vermelhos com falhas de servidor, D escuro e fora do ar, setas descendo na cadeia

Análise:

Um pequeno problema no Serviço A cascateou pela cadeia de dependências

Ações:

Circuit breakers para deter a cascata
Timeouts em cada nível de serviço
Fallbacks para dependências com falha
Corrigir a causa raiz no Serviço A

Boas práticas de dashboard

Seis práticas recomendadas de dashboard para monitorar a saúde da aplicação

Resumo do vídeo e conclusão do curso

Projete usando hierarquia da informação e os quatro sinais de ouro
Combine métricas do CloudWatch, traces do X-Ray e logs em uma só visão
Fluxo de 7 passos: identificar → delimitar → correlacionar → aprofundar → causa raiz → corrigir → verificar

Agora você consegue:

Monitorar com métricas, logs e dashboards do CloudWatch
Configurar alarmes e notificações com SNS e SQS
Implementar tracing distribuído com X-Ray
Criar dashboards de saúde da aplicação para excelência operacional

Dashboards de saúde da aplicação

Monitoramento e Solução de Problemas na AWS