CloudWatch para OTel: Desmontando o Padrão de Bridge de Observabilidade

Toda organização que cresce além de dois ou três times de engenharia enfrenta a mesma tensão: serviços AWS emitem métricas nativamente para o CloudWatch — Lambda, RDS, EKS, API Gateway, MSK — mas o backend de observabilidade corporativo fala OTLP. O resultado é um mundo partido: SREs precisam abrir dois consoles para correlacionar um incidente, alertas vivem em namespaces diferentes, e dashboards de negócio ficam impossíveis de construir sem ETL manual.

O padrão de bridge existe para resolver exatamente isso. A ideia central é simples: uma função Lambda (ou um coletor OTel rodando em ECS/EKS) subscreve streams de métricas do CloudWatch via CloudWatch Metric Streams ou polling da API GetMetricData, transforma o payload para o formato OTLP (OpenTelemetry Protocol), e o encaminha para um endpoint de coletor. Na teoria, você ganha um único plano de controle de observabilidade. Na prática, a complexidade se esconde nos detalhes.

O que torna esse problema especialmente traiçoeiro em ambientes financeiros é a combinação de três fatores: (1) volume de métricas — uma conta AWS de médio porte com EKS, RDS Multi-AZ e Lambda pode gerar facilmente 50.000+ séries de métricas por minuto; (2) latência de negócio — SLOs de detecção de anomalia exigem freshness de 60 segundos ou menos; (3) custo de API — cada chamada GetMetricData tem custo direto e quota de 50 métricas por request, o que significa que polling ingênuo em escala quebra tanto o orçamento quanto os rate limits da AWS.

O padrão tem dois sabores de ingestão, e a escolha entre eles define tudo que vem depois.

CloudWatch Metric Streams + Kinesis Firehose é o caminho de baixa latência. Streams entregam dados em formato OpenTelemetry 0.7 (protobuf) ou JSON com latência de 2–3 segundos. O custo é previsível: $0.003 por 1.000 atualizações de métrica. Para uma conta com 100k séries ativas, isso é aproximadamente $300/mês antes do custo do Firehose. A vantagem arquitetural crítica é que você não está fazendo polling — o dado flui, e a Lambda no destino do Firehose recebe batches, não chamadas individuais.

Polling via GetMetricData é o caminho de controle granular. Você escolhe exatamente quais métricas, com qual resolução e qual período de lookback. Mas a API tem quota de 50 métricas por request e 500 requests por segundo por conta (soft limit). Em uma conta grande, atingir esse limite é questão de minutos se o código de polling não implementar backoff exponencial com jitter e não batchear corretamente. Vi sistemas financeiros em produção quebrarem alertas críticos porque o poller entrou em throttling às 09:00 de uma segunda-feira — exatamente quando o mercado abre e o volume de transações explode.

A Lambda de transformação precisa de três capacidades não-negociáveis: (1) idempotência — Firehose pode re-entregar batches em caso de falha; a Lambda deve detectar duplicatas via hash do payload; (2) circuit breaker para o endpoint OTel externo — se o coletor estiver down, a Lambda não pode ficar em loop consumindo concorrência; (3) DLQ com alarme — batches que falham após 3 tentativas vão para SQS DLQ e um alarme CloudWatch deve disparar em menos de 5 minutos.

Em ambientes financeiros, o bridge de observabilidade é um vetor de exfiltração de dados subestimado. Métricas de negócio — volume de transações, latência de pagamentos, taxa de erros de autenticação — são informação sensível. Um endpoint OTel mal configurado pode vazar esses dados para fora da conta AWS sem nenhum alarme.

As três camadas de controle que implemento em todo deployment desse padrão:

IAM com condições de recurso: A role da Lambda deve ter permissão cloudwatch:GetMetricData e cloudwatch:ListMetrics com condição aws:ResourceTag/Environment: production — nunca um wildcard. Para Metric Streams, a role do Firehose precisa de cloudwatch:PutMetricStream e firehose:PutRecord, mas a role da Lambda de destino deve ser separada e ter apenas s3:GetObject no bucket de buffer (se usar S3 como fallback) e permissão de invocação.

KMS CMK para payload em trânsito: O Firehose deve ser configurado com ServerSideEncryption usando uma CMK gerenciada pelo time de segurança. A Lambda de transformação deve descriptografar com a mesma chave. Isso garante que mesmo um acesso não autorizado ao stream do Firehose não expõe dados legíveis.

VPC Endpoint para o coletor OTel: Se o coletor roda em ECS dentro da VPC, a Lambda deve estar na mesma VPC e usar DNS privado. Se o coletor é externo (SaaS), o tráfego deve sair por um NAT Gateway com IP fixo whitelistado no firewall do fornecedor — nunca por Internet Gateway sem controle de saída. Adicione um WAF rule no API Gateway se o coletor externo expõe um endpoint HTTP.

Um detalhe que queimou um cliente meu: a Lambda de bridge rodando com timeout de 15 minutos (máximo) e sem reserva de concorrência pode consumir todo o pool de concorrência da conta em um pico de ingestão, derrubando funções de negócio críticas. Reserve concorrência explícita — tipicamente 10–20 instâncias são suficientes para um Firehose com batch de 5MB.

Depois de implementar e depurar esse padrão em três ambientes financeiros diferentes, o design que funciona tem estas características concretas:

Ingestão via Metric Streams com filtro de namespace: Configure o stream para incluir apenas os namespaces relevantes — AWS/Lambda, AWS/EKS, AWS/RDS, AWS/ApiGateway, AWS/MSK — e exclua explicitamente namespaces de custo alto e baixo valor como AWS/Billing e AWS/CloudFront (a menos que você monitore CDN). O formato deve ser opentelemetry0.7 (protobuf), não JSON, para reduzir o tamanho do payload em ~40%.

Firehose com buffer de 60s/5MB e S3 como fallback: Configure BufferingHints com IntervalInSeconds: 60 e SizeInMBs: 5. O S3 de fallback deve ter lifecycle policy para expirar objetos em 7 dias — ele existe apenas para replay manual em caso de falha do coletor externo, não como storage permanente.

Lambda de transformação em Python/Rust com SDK OTel: Use o opentelemetry-sdk para construir o payload OTLP. Adicione resource attributes fixos no momento da transformação: cloud.account.id, cloud.region, deployment.environment. Esses atributos permitem correlação cross-account no backend. O timeout deve ser 3 minutos (não 15) — se a transformação de um batch leva mais de 3 minutos, há um problema de volume que precisa ser resolvido no filtro do stream, não no timeout.

Observabilidade do próprio bridge: Instrumente a Lambda com métricas customizadas: bridge.metrics.transformed.count, bridge.export.latency.p99, bridge.export.errors.count. Crie um dashboard CloudWatch para o bridge em si — é irônico mas necessário: você precisa observar o sistema de observabilidade. Defina um SLO de bridge.export.errors.count < 0.1% com alarme de 5 minutos de burn rate.