Observabilidade: métricas, logs e rastros que ajudam a decidir

Observabilidade não é guardar toda telemetria possível. É conseguir transformar sinais do sistema em decisões operacionais verificáveis.

10h02: o atendimento informa que pedidos estão “travando” O monitor de CPU está normal. O banco está respondendo. Todos os containers aparecem como ativos. O healthcheck retorna 200 . Ainda assim, pessoas não conseguem concluir pedidos. Esse cenário hipotético mostra a diferença entre verificar componentes e observar uma experiência. A investigação só começa quando a equipe transforma “está travando” em perguntas: 1. quantos pedidos foram afetados; 2. desde quando; 3. em qual etapa; 4. em quais versões; 5. quais dependências participaram; 6. qual erro apareceu; 7. o que mudou pouco antes. Observabilidade é a capacidade de usar os sinais emitidos pelo sistema para responder a perguntas sobre seu comportamento, inclusive perguntas que não foram antecipadas exatamente daquela forma. Ela não é sinônimo de instalar um dashboard. 10h04: encontre primeiro o impacto Antes de procurar a causa, confirme o sintoma. Uma métrica de resultado pode mostrar: A primeira conclusão não é “o banco está lento”. É: Pessoas que chegam ao checkout estão levando mais tempo e concluindo menos pedidos. Essa distinção segue uma recomendação central do capítulo Monitoring Distributed Systems, do Google SRE: alertas devem priorizar sintomas que afetam o serviço, e não toda causa interna possível. Os quatro sinais clássicos apresentados pelo Google são: latência; tráfego; erros; saturação. Eles são um ponto de partida, não um catálogo completo. Para um produto, também podem ser necessários sinais de negócio: pedidos concluídos; mensagens entregues; autenticações válidas; documentos processados; tarefas abandonadas; cobranças confirmadas; tempo até conclusão. Infraestrutura saudável não garante resultado funcional. 10h06: identifique a versão antes de investigar Todo sinal precisa dizer a que pertence. No mínimo: serviço; ambiente; versão; instância; região ou nó quando relevante. Exemplo: As convenções semânticas do OpenTelemetry definem atributos compartilhados para tornar sinais produzidos por bibliotecas e serviços mais consistentes. Sem versão, a equipe vê um aumento de erros, mas não sabe se começou com o deploy. Sem ambiente, um dashboard pode misturar homologação e produção. Sem serviço, todos os logs viram uma grande sequência indistinguível. 10h08: métricas mostram onde ampliar Métricas representam medições agregadas ao longo do tempo. Exemplos: Elas são adequadas para: detectar tendência; comparar versões; calcular taxa; medir percentis; observar saturação; gerar alertas; verificar objetivos. Uma métrica não deveria incluir cada detalhe de cada requisição. Exemplo perigoso: Cada valor diferente cria uma nova série temporal. Isso aumenta cardinalidade, custo e risco de exposição. Labels adequadas costumam possuir conjuntos limitados: Não use a URL bruta com IDs como label. Normalize rotas. 10h10: um alerta revela o começo da regressão Regra Prometheus hipotética: Os valores são ilustrativos. Um limite adequado depende do volume, do SLO e da tolerância do produto. O for: 10m reduz disparos por picos muito curtos. Também pode atrasar a detecção. A escolha precisa refletir o impacto. Um alerta acionável deve informar: qual sintoma ocorreu; qual serviço está afetado; há quanto tempo; qual gravidade; onde investigar; quem responde; qual runbook; como validar a recuperação. Alerta “CPU alta” sem impacto, duração ou contexto frequentemente cria ruído. 10h12: logs mostram o evento específico A equipe filtra logs pela versão 2.14.0 . Encontra: Esse evento é mais útil do que: E mais seguro do que: Logs estruturados facilitam: filtro; agregação; correlação; detecção; retenção diferenciada. Um log útil descreve um evento. Não precisa contar toda a história em uma única linha. Campos comuns: timestamp; nível; serviço; versão; ambiente; evento; código de erro; identificador de correlação; duração; atributos não sensíveis. Evite registrar: senha; token; cookie; chave; dados completos de pagamento; corpo integral por padrão; documentos; dados pessoais sem finalidade. Logs são dados operacionais e também precisam de: controle de acesso; retenção; criptografia; descarte; auditoria; mascaramento. 10h14: o rastro atravessa a fronteira que o log não enxerga O trace id leva a um rastro: O backend local não estava saturado. A maior parte do tempo foi consumida na dependência externa. Um trace representa uma operação distribuída. Cada trecho é um span, com: início; duração; relação pai filho; serviço; operação; estado; atributos; eventos. Segundo a página de sinais do OpenTelemetry, traces acompanham o caminho de uma requisição por diferentes componentes e ajudam a compreender relações causais. Tracing é especialmente útil quando: há múltiplos serviços; existem filas; dependências externas participam; a latência está distribuída; logs isolados não explicam a sequência. Para um site simples servido por uma única aplicação, traces extensos podem ter retorno limitado. Comece com métricas e logs bem estruturados. 10h16: a falha é externa, mas a decisão é interna A causa imediata é timeout no gateway de pagamento. A equipe ainda precisa decidir: aumentar timeout; repetir; colocar em fila; devolver erro; bloquear novos pedidos; usar outro provedor; ativar modo degradado; reverter o deploy. “Gateway lento” não encerra a investigação. A nova versão alterou o timeout de 10 para 3 segundos. O gateway sempre apresentou respostas ocasionais entre três e quatro segundos, mas isso não era visível no teste de homologação. A decisão pode ser retornar à configuração anterior enquanto a equipe revisa o comportamento. Observabilidade não elimina julgamento. Ela oferece evidência para que o julgamento não dependa apenas de opinião. Métrica, log e trace não competem Sinal Pergunta forte Métrica O problema existe, cresce e afeta quanto? Log Qual evento ocorreu em determinada execução? Trace Onde o tempo e a falha atravessaram os componentes? Profile Onde o processo consumiu CPU ou memória ao longo do tempo? Evento de negócio A tarefa da pessoa foi concluída? Não existe obrigação de coletar todos para toda aplicação. A melhor combinação é a menor que permita: 1. detectar; 2. dimensionar; 3. localizar; 4. compreender; 5. validar a correção. Correlação vale mais do que volume Considere estes dados separados: dashboard de erro; arquivo de log; trace; histórico de deploy; ticket de atendimento. Se cada um usa identificadores diferentes, a investigação ainda depende de trabalho manual. Use correlação: Exemplo: Isso permite partir do alerta, encontrar a versão, abrir o trace e localizar os eventos relacionados. O healthcheck não deve responder por tudo Um endpoint /health pode indicar que o processo está vivo. Outro endpoint pode indicar prontidão para receber tráfego. Não use uma única verificação para afirmar que: pagamentos funcionam; banco está consistente; e mail é entregue; usuários concluem tarefas; dados estão corretos. Separação possível: Uma dependência externa instável pode remover prontidão conforme o desenho. Isso precisa ser avaliado com cuidado para não derrubar todas as instâncias simultaneamente. Dashboards precisam responder a uma decisão Dashboard operacional de um serviço: Experiência taxa de sucesso; latência; volume; abandono. Aplicação erros; filas; timeouts; pools; cache. Infraestrutura CPU; memória; disco; rede; reinícios. Mudanças versão; deploys; flags; migrações. Dependências disponibilidade; latência; erros; quotas. Um painel com cinquenta gráficos sem hierarquia é um inventário visual, não uma ferramenta de decisão. Organize a leitura: Alertas: página, ticket ou registro Nem todo desvio deve acordar alguém. Página imediata Condição: impacto atual relevante; resposta urgente; ação conhecida. Ticket Condição: degradação ainda tolerável; capacidade futura; dívida operacional; revisão em horário normal. Registro ou dashboard Condição: informação útil para análise; ausência de ação imediata; tendência ainda sem risco. A orientação do Prometheus recomenda manter alertas simples, orientados por sintomas e vinculados a ações. Um alerta sem ação conhecida pode indicar: telemetria exploratória; necessidade de runbook; limite mal definido; notificação desnecessária. Burn rate é melhor do que limite fixo em muitos serviços Considere um SLO de sucesso. Um alerta fixo de erro acima de 1% pode: disparar demais em baixo volume; disparar tarde em uma falha grande; ignorar o orçamento de erro restante. Alertas de burn rate observam a velocidade com que o serviço consome o orçamento de erro. Esse modelo é aprofundado no artigo sobre SLIs, SLOs e orçamento de erro. Não adote burn rate antes de possuir: SLI correto; SLO definido; dados confiáveis; janela compreendida. Sampling precisa preservar casos importantes Coletar 100% dos traces pode ser caro. Amostragem pode ocorrer: no início da requisição; depois de observar o resultado; por regra; por taxa; por atributo. Exemplos de eventos que merecem retenção maior: erros; alta latência; pagamento; fluxos críticos; versões novas; clientes internos de teste. Cuidados: não distorcer métricas; não perder incidentes raros; manter privacidade; documentar a taxa; compreender o custo do collector; monitorar perda de telemetria. Uma plataforma de observabilidade também pode falhar. Monitore: filas de exportação; drops; latência; armazenamento; ingestão; agentes; collectors. A telemetria precisa sobreviver ao deploy Antes de publicar uma mudança, verifique: nome do serviço; versão; ambiente; métricas existentes; novos códigos de erro; logs relevantes; traces; dashboards; alertas; compatibilidade de queries. Renomear uma métrica pode quebrar alertas. Remover um label pode ocultar a versão. Alterar unidade pode produzir gráficos incorretos. Observabilidade também possui contratos. O fluxo DevOps confiável deve publicar aplicação e capacidade de observá la no mesmo ciclo. Um plano de instrumentação para equipe pequena Fase 1: experiência e deploy Registre: disponibilidade; taxa de erro; latência; volume; versão ativa; histórico de deploy. Fase 2: logs estruturados Padronize: serviço; ambiente; versão; evento; correlação; erro. Fase 3: dependências Meça: banco; fila; cache; serviços externos; timeouts. Fase 4: traces Instrumente fluxos com múltiplas fronteiras. Fase 5: SLO e alertas Transforme sinais em compromisso operacional. Não comece coletando tudo. Comece pela tarefa que a empresa não pode perder. Critério de aceite de observabilidade Uma aplicação não está operacionalmente pronta quando apenas responde ao healthcheck. Ela deve permitir responder: qual versão está ativa; quantas pessoas são afetadas; quando o problema começou; em qual etapa; qual dependência participou; qual erro ocorreu; qual mudança antecedeu; como validar a recuperação. No incidente hipotético, a decisão foi possível porque os sinais estavam conectados: Esse é o valor da observabilidade: não produzir mais gráficos, mas reduzir o intervalo entre “algo está errado” e “sabemos o impacto, a causa provável e a ação mais segura”.