Observabilidade na AWS: CloudWatch, X-Ray e OpenTelemetry

Observabilidade é a capacidade de entender o estado interno de um sistema a partir dos dados que ele emite, permitindo diagnosticar problemas e otimizar performance em tempo real. Na AWS, os três pilares da observabilidade (métricas, logs e traces) são implementados com CloudWatch, X-Ray e OpenTelemetry, complementados por dashboards Grafana para visualização unificada.

Monitorar uma aplicação na nuvem vai muito além de verificar se o servidor está "de pé". Em arquiteturas modernas com microsserviços, containers e funções serverless, entender o que acontece dentro do sistema, e por quê, exige uma abordagem estruturada de observabilidade. Os três pilares clássicos são: métricas, logs e traces.

Neste guia, vamos explorar como implementar observabilidade completa na AWS usando CloudWatch para métricas e logs, X-Ray para distributed tracing, OpenTelemetry como padrão aberto de instrumentação e Grafana para dashboards unificados.

Os três pilares da observabilidade

Antes de mergulhar nas ferramentas, é fundamental entender o que cada pilar oferece:

• Métricas: dados numéricos agregados ao longo do tempo (CPU, latência, taxa de erros, requests por segundo). Respondem à pergunta "o que está acontecendo?"
• Logs: registros textuais de eventos discretos (erros, transações, auditoria). Respondem à pergunta "por que aconteceu?"
• Traces: rastreamento do caminho de uma requisição através de múltiplos serviços. Respondem à pergunta "onde está o gargalo?"

Um sistema verdadeiramente observável integra os três pilares de forma correlacionada: a partir de uma métrica anômala, você navega para os logs relevantes e, de lá, para o trace completo da requisição problemática.

CloudWatch: o centro de monitoramento da AWS

O Amazon CloudWatch é o serviço nativo de monitoramento da AWS. Ele coleta métricas automaticamente de praticamente todos os serviços AWS (EC2, RDS, Lambda, ECS, etc.) e permite criar métricas customizadas, alarmes, dashboards e automações.

Métricas e alarmes

CloudWatch recebe métricas em namespaces organizados por serviço. Além das métricas padrão, você pode publicar métricas customizadas da sua aplicação:

// Alarme para taxa de erros 5xx acima de 5% por 5 minutos
{
  "AlarmName": "API-HighErrorRate",
  "AlarmDescription": "Taxa de erros 5xx acima de 5% nos últimos 5 minutos",
  "Namespace": "AWS/ApplicationELB",
  "MetricName": "HTTPCode_Target_5XX_Count",
  "Statistic": "Sum",
  "Period": 300,
  "EvaluationPeriods": 1,
  "Threshold": 50,
  "ComparisonOperator": "GreaterThanThreshold",
  "TreatMissingData": "notBreaching",
  "AlarmActions": [
    "arn:aws:sns:sa-east-1:123456789:alertas-produção"
  ],
  "OKActions": [
    "arn:aws:sns:sa-east-1:123456789:alertas-produção"
  ],
  "Dimensions": [
    {
      "Name": "LoadBalancer",
      "Value": "app/meu-alb/1234567890"
    }
  ],
  "Tags": [
    {
      "Key": "Environment",
      "Value": "production"
    },
    {
      "Key": "Severity",
      "Value": "critical"
    }
  ]
}

CloudWatch Logs e Logs Insights

O CloudWatch Logs centraliza logs de aplicações, serviços AWS e infraestrutura. O recurso mais poderoso é o CloudWatch Logs Insights, que permite consultas SQL-like em tempo real sobre seus logs:

# Top 10 erros mais frequentes nas últimas 24h
fields @timestamp, @message
| filter @message like /ERROR/
| stats count(*) as total by @message
| sort total desc
| limit 10

# Latência P99 por endpoint nos últimos 30 min
fields @timestamp, endpoint, duration_ms
| filter ispresent(duration_ms)
| stats percentile(duration_ms, 99) as p99,
        percentile(duration_ms, 95) as p95,
        avg(duration_ms) as média
  by endpoint
| sort p99 desc

# Requests com latência acima de 3 segundos
fields @timestamp, @message, endpoint, duration_ms, trace_id
| filter duration_ms > 3000
| sort @timestamp desc
| limit 20

Dica importante: sempre inclua o trace_id nos seus logs. Isso permite correlacionar logs com traces do X-Ray, criando uma experiência de debugging integrada.

AWS X-Ray: distributed tracing

Em arquiteturas com múltiplos microsserviços, uma única requisição pode percorrer dezenas de serviços. Quando algo dá errado ou a latência aumenta, identificar o serviço problemático sem tracing é como procurar agulha no palheiro.

O AWS X-Ray resolve isso rastreando cada requisição end-to-end, gerando um mapa visual dos serviços e identificando gargalos de performance. Para instrumentar sua aplicação, basta adicionar o SDK do X-Ray:

# Instrumentação do X-Ray em aplicação Python (Flask)
from aws_xray_sdk.core import xray_recorder
from aws_xray_sdk.ext.flask.middleware import XRayMiddleware
from aws_xray_sdk.core import patch_all
import flask

# Patch automático para boto3, requests, sqlite3, etc.
patch_all()

app = flask.Flask(__name__)

# Configurar X-Ray com sampling rules
xray_recorder.configure(
    sampling=True,
    context_missing='LOG_ERROR',
    plugins=('EC2Plugin', 'ECSPlugin'),
    daemon_address='127.0.0.1:2000'
)

# Adicionar middleware ao Flask
XRayMiddleware(app, xray_recorder)

@app.route('/api/pedidos')
def listar_pedidos():
    # Subsegmento customizado para lógica de negócio
    with xray_recorder.in_subsegment('validar_permissões') as subsegment:
        subsegment.put_annotation('user_id', '12345')
        subsegment.put_metadata('request_params', request.args)
        validar_acesso(request)

    # Chamadas a DynamoDB e outros serviços são
    # automaticamente rastreadas pelo patch_all()
    pedidos = dynamodb.Table('pedidos').scan()
    return jsonify(pedidos['Items'])

O X-Ray gera automaticamente um Service Map visual que mostra todas as dependências entre serviços, latências médias e taxas de erro. Isso é extremamente valioso para entender a topologia real da sua aplicação em produção.

OpenTelemetry: o padrão aberto

O OpenTelemetry (OTel) é um projeto open-source da CNCF que fornece APIs, SDKs e ferramentas padronizadas para gerar, coletar e exportar dados de telemetria (métricas, logs e traces). A principal vantagem é a portabilidade: você instrumenta uma vez e pode enviar dados para qualquer backend (CloudWatch, X-Ray, Grafana, Datadog, etc.).

A AWS suporta nativamente o OpenTelemetry através do AWS Distro for OpenTelemetry (ADOT), uma distribuição oficial que inclui coletores otimizados e exportadores para serviços AWS.

# Configuração do ADOT Collector
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 10s
    send_batch_size: 1024
  memory_limiter:
    check_interval: 5s
    limit_mib: 512
    spike_limit_mib: 128

exporters:
  awsxray:
    region: sa-east-1
    index_all_attributes: true
  awsemf:
    region: sa-east-1
    namespace: MinhaApp
    log_group_name: '/otel/métricas'
    dimension_rollup_option: "NoDimensionRollup"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, memory_limiter]
      exporters: [awsxray]
    metrics:
      receivers: [otlp]
      processors: [batch, memory_limiter]
      exporters: [awsemf]

Com essa configuração, o ADOT Collector recebe dados via protocolo OTLP (OpenTelemetry Protocol) e exporta traces para o X-Ray e métricas para o CloudWatch. Sua aplicação precisa apenas enviar dados para o collector via OTLP, sem dependência direta de SDKs proprietários da AWS.

Dashboards com Grafana

Embora o CloudWatch ofereça dashboards nativos, o Amazon Managed Grafana proporciona uma experiência muito mais rica para visualização. O Grafana suporta múltiplas fontes de dados (CloudWatch, X-Ray, Prometheus, Elasticsearch) em um único dashboard, facilitando a correlação entre os três pilares da observabilidade.

Para ambientes com múltiplas contas AWS ou estratégia multi-cloud, o Grafana se torna essencial como camada unificada de visualização. A versão gerenciada pela AWS elimina a complexidade de operar o Grafana, incluindo autenticação via AWS IAM Identity Center e integração nativa com fontes de dados AWS.

Melhores práticas de observabilidade na AWS

1. Structured logging

Sempre emita logs em formato JSON estruturado. Isso facilita consultas no Logs Insights e correlação com traces. Em pipelines CI/CD, configure a instrumentação como parte do build para garantir rastreabilidade desde o deploy. Inclua campos como trace_id, request_id, user_id, endpoint e duration_ms em cada log entry.

2. Métricas de negócio, não só de infra

Além de CPU e memória, publique métricas de negócio no CloudWatch: pedidos por minuto, valor de transações, tempo de processamento de pagamentos. Essas métricas são as que realmente importam para o stakeholder.

3. Alarmes com runbooks

Todo alarme deve ter um runbook associado: um documento que descreve o que o alarme significa, como investigar e quais ações tomar. Alarme sem runbook gera "alert fatigue" e é ignorado.

4. Sampling inteligente

Em ambientes de alto throughput, coletar 100% dos traces é inviável e caro. Configure sampling rules no X-Ray para capturar 100% dos erros é uma amostra representativa (1-5%) dos requests bem-sucedidos.

5. SLIs, SLOs e Error Budgets

Defina Service Level Indicators (métricas que representam a experiência do usuário), Service Level Objectives (metas para essas métricas) e Error Budgets (margem aceitável de degradação). Isso transforma observabilidade em uma ferramenta de decisão, não apenas de diagnóstico.

"Observabilidade não é sobre ter dashboards bonitos, é sobre reduzir o tempo entre 'algo está errado' e 'encontramos e corrigimos o problema'. Cada minuto conta."

Stack recomendada pela RFX Tecnologia

Para a maioria dos cenários na AWS, recomendamos a seguinte stack de observabilidade:

• Instrumentação: OpenTelemetry (ADOT) para portabilidade e padronização
• Métricas: CloudWatch Metrics + Amazon Managed Prometheus para workloads em Kubernetes
• Logs: CloudWatch Logs com Logs Insights para consultas ad-hoc
• Traces: AWS X-Ray integrado via ADOT Collector
• Dashboards: Amazon Managed Grafana com fontes de dados unificadas
• Alertas: CloudWatch Alarms + SNS + PagerDuty/Opsgenie para on-call

Gotchas e custos ocultos do CloudWatch

Erros comuns que impactam custo e efetividade:

• Logs sem retention policy: por padrão, CloudWatch Logs nunca expira. Uma aplicação que gera 10 GB/dia de logs vai acumular 3.6 TB/ano, custando aproximadamente USD 1.800/ano só em armazenamento. Configure retention de 30-90 dias para ambientes de dev e 365 dias para produção.
• Custom metrics com alta cardinalidade: cada combinação única de dimensões cria uma métrica separada. Se voce publica uma métrica com dimensão user_id e tem 100.000 usuários, serão 100.000 métricas (USD 30.000/mes). Use métricas agregadas e reserve alta cardinalidade para traces.
• Alarmes sem ação: mais de 50% dos alarmes que encontramos em auditorias não tem action configurada ou notificam canais que ninguém monitora. Todo alarme deve ter: SNS topic ativo, runbook documentado e responsável definido.
• X-Ray com sampling de 100%: em aplicações com alto throughput (mais de 1.000 req/s), capturar todos os traces gera custo proibitivo e poluição de dados. Configure sampling rules: 100% para erros, 5% para requests normais, 100% para requests lentos (acima do P95).

# Configurar retention de 90 dias em todos os log groups
for lg in $(aws logs describe-log-groups \
  --query 'logGroups[?!retentionInDays].logGroupName' \
  --output text --region sa-east-1); do
  echo "Configurando retention para $lg..."
  aws logs put-retention-policy \
    --log-group-name "$lg" \
    --retention-in-days 90 \
    --region sa-east-1
done

# Criar alarme composto (Composite Alarm) para reduzir ruído
aws cloudwatch put-composite-alarm \
  --alarm-name "Producao-Critico" \
  --alarm-rule 'ALARM("API-HighErrorRate") AND ALARM("API-HighLatency")' \
  --alarm-actions "arn:aws:sns:sa-east-1:123456789:pagerduty-critico" \
  --region sa-east-1

# Configurar X-Ray sampling rule (5% para requests normais)
aws xray create-sampling-rule --sampling-rule '{
  "RuleName": "default-low-sample",
  "Priority": 1000,
  "FixedRate": 0.05,
  "ReservoirSize": 1,
  "ServiceName": "*",
  "ServiceType": "*",
  "Host": "*",
  "ResourceARN": "*",
  "HTTPMethod": "*",
  "URLPath": "*",
  "Version": 1
}'

Na Prática: observabilidade para e-commerce

Um e-commerce com 200.000 pedidos/mes operava com monitoramento básico: apenas alarmes de CPU e disco. Quando a taxa de erros subia na Black Friday, o time levava horas para identificar a causa raiz, resultando em perda estimada de R$ 50.000 por hora de degradação.

• Semana 1-2: instrumentamos os 12 microsserviços com OpenTelemetry (ADOT como sidecar no ECS), configuramos structured logging em JSON com trace_id, request_id e campos de negócio (order_id, payment_method).
• Semana 3: criamos dashboards no Amazon Managed Grafana com três níveis: executivo (pedidos/min, receita, SLA), operacional (latencia P99, error rate por serviço) e debug (traces lentos, logs de erro filtrados).
• Semana 4: implementamos alarmes compostos (Composite Alarms) para reduzir falsos positivos e configuramos runbooks no Systems Manager com ações automatizadas (ex: scale-up automático quando latencia P99 ultrapassa 2s).

Resultado: MTTR caiu de 4 horas para 12 minutos. Na Black Friday seguinte, a equipe identificou e resolveu um gargalo no serviço de pagamentos (connection pool do RDS saturado) em 8 minutos, antes que impactasse o cliente final. O custo de observabilidade (CloudWatch + X-Ray + Grafana) ficou em USD 380/mes, menos de 0,01% da receita mensal.

Próximos passos

A observabilidade é uma capacidade que evolui com a maturidade da equipe. Comece com métricas básicas e alarmes, evolua para structured logging e Logs Insights, e por fim implemente distributed tracing com X-Ray e OpenTelemetry.

Na RFX Tecnologia, por meio do nosso serviço de DevOps e Automação, implementamos soluções de observabilidade completas na AWS, desde a instrumentação até dashboards executivos. Ajudamos equipes a reduzir o MTTR (Mean Time to Recovery) é a ganhar confiança na operação de sistemas críticos. Agende uma consultoria gratuita para avaliar a maturidade de observabilidade do seu ambiente.