Analisando traces e mapas de serviços

Monitoramento e Solução de Problemas na AWS

John Q. Martin

Principal Consultant

O que é um service map?

Gerado automaticamente a partir dos seus traces: sem configuração manual

Quadro de partidas ferroviárias com linhas de serviços, cada uma com uma luz de status colorida: verde para no horário, âmbar para atrasado, vermelho para parado

De relance: verde = no horário · âmbar = atrasado · vermelho = parado

Acesse assim:

Console do X-Ray → Service map
Aplique filters
Clique em um node → detalhamento

Cores no service map

Legenda de cores do service map: verde chamadas bem-sucedidas, amarelo erros do cliente, vermelho falhas no servidor, roxo throttling, cinza sem tráfego

Ao abrir um service map, vá direto ao que não está verde.

Clique em qualquer nó para ver: distribuição de tempo de resposta, status HTTP, tipos de erro.

Lendo um service map

Service map com API Gateway e OrderService abrindo para DynamoDB Inventory e um serviço Payment amarelo

Análise do caminho crítico

Caminho crítico = cadeia mais longa de chamadas

API Gateway (50ms)
  -> OrderService (50ms)
    -> PaymentService (100ms)
      -> External API (200ms)

Total: 400ms

External API = 50% da latência total

O que fazer com isso:

External API é seu alvo de otimização
Opções: adicionar cache, implementar timeout + fallback, negociar SLAs

Compare caminho alternativo:

OrderService -> DynamoDB
Total: 120ms (rápido)

Riscos de dependência

Riscos de dependência no service map: dependências circulares, pontos únicos de falha e dependências externas arriscadas

Entendendo linhas do tempo de traces

Linha do tempo de trace com subsegmentos ao longo do tempo mostrando uma chamada payment-api como a operação mais longa

Eixo horizontal tempo: quando as operações começaram e quanto duraram
Eixo vertical hierarquia de serviços: subsegmentos indentados sob os pais
HTTP.POST para payment-api (100-250ms) = a operação única mais longa

Padrão 1: Gargalos sequenciais

Antes (sequencial - 80ms):

Query 1 (10-30ms)
         -> Query 2 (30-50ms)
                  -> Query 3 (50-70ms)
                           -> Query 4 (70-90ms)

Depois (paralelo - 20ms):

Linha do tempo de quatro queries rodando em paralelo, sobrepostas para terminar em 20ms

Padrão 2: Consultas N+1 e serviços "falantes"

Problema de consultas N+1:

Get user list       (10-20ms)
Get user 1 details  (20-30ms)
Get user 2 details  (30-40ms)
... ×100 consultas sequenciais

Correção: agrupar consultas, eager loading

Serviços "falantes":

50 chamadas pequenas entre dois serviços em vez de 1 em lote
Cada chamada: criação de conexão + serialização + ida e volta
50× o overhead

Correção: agrupar requisições, filas de mensagens, cache

Padrão 3: Cold starts e falhas em cascata

Duas barras de tempo: um cold start tem um grande bloco laranja de inicialização e um pequeno handler verde; um warm start é só o pequeno handler verde

Lambda Cold Start:

Frio: 3000ms (2500ms init + 500ms handler)
Quente: 500ms (apenas handler)
Visível como um grande segmento de init na primeira invocação

Correção: provisioned concurrency, otimizar inicialização

Falha em cascata:

Service A [Error]
  -> Service B [Timeout 5s]
    -> Service C [Timeout 5s]
      -> Database [Timeout 5s]

Blocos de timeout iguais empilhados pela hierarquia do trace

Correção: timeouts, circuit breakers, fallbacks

Filtrando traces com anotações

Console do X-Ray filtrando traces por pares chave-valor de anotação

Compare grupos:

Usuários premium média 200ms vs. gratuitos média 150ms → recursos premium adicionando latência
UE Oeste 3× mais lento que EUA Leste → acesso a dados entre regiões

Fluxo de análise de traces

Identificar - filtro: response_time > 1000ms, ordenar por duração
Analisar - achar operações mais longas, gargalos sequenciais, oportunidades de paralelismo
Anotar - ver anotações para contexto de negócio: ID de usuário, ID de pedido, ambiente
Revisar - examinar metadados: detalhes da requisição, mensagens de erro
Correlacionar - cruzar com CloudWatch Logs
Diagnosticar - causa raiz: consulta lenta, timeout, algoritmo, exaustão de recursos
Corrigir - otimizar código, adicionar cache, paralelizar, escalar
Verificar - comparar traces antes/depois, monitorar latência e taxa de erros

Criando alertas a partir de dados do X-Ray

# Alarme de alta latência
aws cloudwatch put-metric-alarm \
  --alarm-name HighLatency \
  --metric-name ResponseTime \
  --namespace AWS/XRay \
  --statistic Average \
  --period 300 \
  --threshold 1000 \
  --comparison-operator GreaterThanThreshold

# Alarme de alto número de erros
aws cloudwatch put-metric-alarm \
  --alarm-name HighErrorCount \
  --metric-name ErrorCount \
  --namespace AWS/XRay \
  --statistic Sum \
  --period 300 \
  --threshold 50 \
  --comparison-operator GreaterThanThreshold

Resumo do vídeo

Service maps - diagramas de arquitetura gerados automaticamente: nós (serviços), arestas (conexões), saúde por cor
Cores - verde (sucesso), amarelo (4xx), vermelho (falhas 5xx), roxo (429), cinza (sem tráfego)
Caminho crítico - cadeia mais longa, indica seu alvo de otimização
Linhas do tempo de traces - revelam gargalos sequenciais, consultas N+1, cold starts, falhas em cascata
Anotações - filtre e agrupe traces por contexto de negócio
Fluxo - oito etapas: identificar → analisar → anotar → revisar → correlacionar → diagnosticar → corrigir → verificar

Analisando traces e mapas de serviços

Monitoramento e Solução de Problemas na AWS