Observabilidade: Logs, Métricas, Traces e Boas Práticas
Entenda observabilidade e monitoramento, métricas, logs, traces, SLI, SLO, alertas acionáveis, resposta a incidentes e controle de custos.
Observabilidade é a capacidade de compreender o estado interno de um sistema a partir dos sinais que ele produz.
Métricas, logs, traces e perfis ajudam equipes a detectar impacto, investigar comportamentos inesperados e aprender por que uma aplicação falhou — inclusive quando ninguém previu aquela falha.
Monitoramento continua essencial, mas responde principalmente a perguntas conhecidas: o serviço está disponível, a latência ultrapassou o limite, o disco está enchendo?
A observabilidade amplia esse alcance ao permitir explorar relações, contexto e causas em sistemas distribuídos. Uma prática não substitui a outra.
Neste guia, você entenderá as diferenças, os principais sinais, como definir SLI e SLO, criar alertas acionáveis, desenhar dashboards, responder a incidentes e controlar o custo da telemetria.
O foco é construir um processo útil para pessoas e usuários, não apenas acumular gráficos.
O que é observabilidade?
Observabilidade descreve quanto é possível inferir sobre o funcionamento interno de um sistema pelos dados que ele expõe.
Na prática de software, isso significa registrar sinais com contexto suficiente para investigar perguntas previstas e imprevistas: qual grupo de usuários foi afetado, em qual versão começou, qual dependência ficou lenta e por que apenas uma região falhou?
Em uma prática madura, telemetria bem instrumentada ajuda a entender o comportamento sem depender de novo código para cada pergunta.
A qualidade vem da estrutura, do contexto e da capacidade de correlacionar dados, não apenas do volume coletado.
Observabilidade não é uma ferramenta
Comprar uma plataforma não torna um sistema observável. Aplicações precisam emitir sinais úteis, propagar contexto e manter convenções consistentes.
Equipes precisam saber quais jornadas importam, quem responde aos alertas e como aprender com incidentes.
A ferramenta coleta, armazena e consulta; o resultado depende do desenho sociotécnico completo.
Monitoramento e observabilidade: qual é a diferença?
Monitoramento acompanha condições definidas: disponibilidade, taxa de erros, uso de CPU ou atraso de uma fila.
Ele mostra se algo conhecido ultrapassou um limite. Observabilidade oferece meios para explorar o estado do sistema e investigar a causa de um comportamento que talvez não tenha uma regra pronta.
| Aspecto | Monitoramento | Observabilidade |
|---|---|---|
| Pergunta central | O que conhecido está fora do esperado? | Por que o sistema está se comportando assim? |
| Uso principal | Detectar, alertar e acompanhar tendências | Explorar, correlacionar e diagnosticar |
| Dados | Métricas e testes predefinidos | Sinais contextualizados e consultáveis |
| Resultado | Consciência de uma condição | Compreensão suficiente para decidir |
White-box e black-box monitoring
Monitoramento white-box observa o interior: filas, conexões, memória, logs e operações. O black-box testa de fora como um usuário, verificando se uma página abre ou uma API responde corretamente.
O capítulo de monitoramento de sistemas distribuídos do Google SRE recomenda combinar os dois: o externo confirma o sintoma; o interno oferece pistas para o diagnóstico.
Os principais sinais de observabilidade
A documentação de sinais do OpenTelemetry inclui traces, métricas, logs e baggage, além de perfis em evolução. Cada sinal responde melhor a um tipo de pergunta.
A combinação permite sair de um indicador agregado e chegar à operação específica que sofreu o problema.
Métricas
Métricas são valores numéricos agregados ao longo do tempo: requisições por segundo, duração, erros, tamanho de fila e uso de recursos. São compactas, adequadas a tendências, dashboards e alertas.
Contadores medem acumulados; gauges representam valores que sobem e descem; histogramas mostram distribuições e percentis.
Uma média pode esconder a cauda. Se uma pequena parcela das requisições leva vários segundos, o valor médio ainda pode parecer saudável.
Histogramas e percentis ajudam a enxergar essa experiência, desde que buckets, janela e volume sejam interpretados corretamente.
Logs
Logs registram eventos: uma autenticação negada, uma tentativa de pagamento ou uma exceção.
Prefira formato estruturado com timestamp, severidade, serviço, ambiente, versão e identificadores de correlação. Mensagens livres são fáceis de começar, porém difíceis de consultar de forma consistente.
Não registre senhas, tokens ou dados pessoais desnecessários. Também evite transformar cada linha executada em evento: além do custo, excesso de ruído piora a investigação.
O log útil explica uma transição ou decisão relevante.
Traces distribuídos
Um trace acompanha a jornada de uma requisição entre serviços. Cada etapa é um span com duração, status e atributos. Isso revela se o tempo foi gasto no gateway, na aplicação, no banco ou em uma API externa.
A propagação de contexto liga os spans e permite conectar o mesmo identificador aos logs.
Para a implementação detalhada de APIs, SDKs e Collector, consulte o guia específico de OpenTelemetry. Aqui, a tecnologia aparece como padrão de instrumentação, não como destino obrigatório de armazenamento.
Perfis contínuos
Perfis mostram onde CPU, memória e outros recursos são consumidos no nível do código. Ajudam a investigar por que uma operação ficou cara mesmo quando métricas e traces já localizaram o serviço.
Exigem cuidado com sobrecarga, símbolos e retenção, mas completam o diagnóstico de performance.
Por que correlacionar os sinais?
Imagine que o percentil alto de latência aumentou após um deploy. A métrica mostra quando e quanto.
Um exemplar aponta para um trace lento; o trace identifica a chamada ao banco; o log correlacionado registra um timeout; o perfil mostra contenção em uma função.
Sem identificadores, atributos e tempo alinhados, a equipe alterna entre telas tentando adivinhar relações.
A documentação do Grafana sobre correlação de telemetria destaca justamente a passagem entre métricas, traces e logs. O objetivo não é centralizar tudo em um produto, mas manter contexto comum para reduzir o tempo entre detecção e explicação.
Os quatro sinais de ouro
O Google SRE recomenda começar por latência, tráfego, erros e saturação em serviços voltados ao usuário.
Esses quatro sinais não cobrem todo sistema, mas criam uma visão inicial orientada à experiência e evitam dashboards formados apenas por CPU e memória.
Latência
Meça a duração de requisições bem-sucedidas e falhas separadamente. Uma resposta de erro pode ser rápida e ainda representar experiência ruim. Observe distribuições por jornada, região ou classe de operação, sem criar rótulos de cardinalidade ilimitada.
Tráfego
É a demanda imposta ao serviço: requisições, sessões, mensagens ou transações. Ela oferece contexto para os demais sinais. Uma taxa de erros igual pode significar situações muito diferentes em um período com dez ou dez mil usuários.
Erros
Inclua falhas explícitas, resultados incorretos e respostas que violam o objetivo de serviço. Um status HTTP 200 não garante que o usuário recebeu o conteúdo certo. Testes sintéticos e métricas de negócio podem capturar falhas invisíveis ao protocolo.
Saturação
Mostra quão cheio está o recurso limitante: pool de conexões, fila, memória, I/O ou capacidade de processamento. Muitos sistemas degradam antes de chegar a 100%. Relacione utilização a latência e estime quando a capacidade será insuficiente.
SLI, SLO e orçamento de erro
Um SLI é o indicador medido, como proporção de requisições válidas abaixo de um limite. O SLO é a meta desse indicador em uma janela, por exemplo 99,9% em 30 dias.
A parcela tolerada de falha é o orçamento de erro. SLA é o compromisso contratual e pode ter consequências comerciais; não deve ser confundido com a meta operacional interna.
Como escolher um SLI útil
Parta de uma jornada: autenticar, pesquisar, pagar ou receber uma mensagem. Defina eventos bons e total de eventos no ponto mais próximo da experiência.
Um indicador de CPU é importante para diagnóstico, mas raramente representa sozinho o que o usuário considera sucesso.
Como definir um SLO realista
Use dados históricos, expectativa do usuário e dependências. Metas mais altas custam mais e podem reduzir velocidade de mudança sem benefício percebido.
O workbook de SRE sobre implementação de SLOs recomenda evoluir metas e indicadores conforme a organização aprende, em vez de buscar precisão perfeita no primeiro documento.
Alertas que ajudam em vez de gerar ruído
Alerta útil é urgente, importante, real e acionável. Deve indicar impacto ou risco iminente, apontar responsável, incluir painel e runbook e evitar duplicatas.
Se ninguém precisa agir, o sinal pertence a um dashboard ou relatório, não ao plantão.
Sintoma antes da causa
A prática de alertas do Prometheus recomenda poucas regras orientadas a sintomas associados ao sofrimento do usuário. CPU alta pode ser pista; erro e latência percebidos são sintomas.
Alertar todas as causas possíveis gera uma tempestade durante um único incidente.
Página, ticket ou dashboard?
- Página: exige resposta humana imediata para limitar impacto.
- Ticket: é acionável, mas pode aguardar o horário de trabalho.
- Dashboard: acompanha tendência ou oferece contexto sem exigir ação.
Agrupe eventos relacionados, use tolerância para oscilações curtas e revise regras após incidentes. Alertas ignorados treinam a equipe a desconfiar justamente do canal que deveria representar urgência.
Dashboards que respondem perguntas
Um dashboard de serviço deve começar pela saúde percebida: SLO, latência, tráfego, erros e saturação. Depois mostra dependências, deploys e capacidade. Evite dezenas de gráficos sem narrativa.
Cada painel precisa apoiar uma decisão de plantão, planejamento ou análise.
Inclua versão implantada e eventos de mudança. Quando uma regressão coincide com o deploy, a equipe pode investigar ou reverter mais rápido. O artigo sobre CI/CD com segurança explica como integrar validação e entrega gradual a esse ciclo.
Arquitetura de uma plataforma de observabilidade
Instrumentação e contexto
Instrumentação pode ser automática, manual ou combinada. A automática cobre frameworks e bibliotecas rapidamente; a manual adiciona semântica de negócio, como carrinho, pagamento ou lote processado.
Padronize nomes de serviço, ambiente, versão e região. Propague trace ID e contexto apenas quando forem seguros.
Coleta, processamento e armazenamento
Agentes e coletores recebem sinais, aplicam filtragem, enriquecimento, amostragem e roteamento. Backends armazenam cada tipo de dado e oferecem consulta, visualização e alertas. Desacoplar instrumentação do destino reduz dependência e permite enviar sinais críticos para mais de um sistema quando necessário.
A própria plataforma precisa de metamonitoramento: perda de amostras, atraso, fila, erros de exportação e indisponibilidade do canal de alertas. Um teste black-box do caminho completo pode revelar que o sistema “saudável” deixou de avisar.
Ferramentas e padrões do ecossistema
OpenTelemetry padroniza instrumentação e transporte; Prometheus é amplamente usado para métricas e alertas; Grafana oferece visualização e correlação; Loki, Elasticsearch e outros sistemas trabalham com logs; Jaeger, Tempo e plataformas comerciais consultam traces. Serviços de nuvem também fornecem stacks integradas.
Escolha pela compatibilidade, volume, retenção, experiência de consulta, controle de acesso, residência dos dados, custo e capacidade da equipe. Não comece pela lista de produtos.
Um processo simples com poucos sinais confiáveis é melhor que uma plataforma sofisticada que ninguém consegue operar.
Resposta a incidentes baseada em telemetria
O alerta inicia a resposta, não encerra o diagnóstico. Defina responsável, canal, papéis e comunicação.
Primeiro confirme impacto e estabilize: rollback, redução de tráfego, desativação de uma função ou aumento temporário de capacidade. Só depois aprofunde a causa.
Antes, durante e depois do incidente
- Antes: SLO, alertas, runbooks, acesso e exercícios.
- Durante: linha do tempo, hipótese, mitigação, comunicação e decisões registradas.
- Depois: post-mortem sem culpabilização, ações com donos e melhoria dos sinais.
Telemetria deve permitir reconstruir a sequência, mas retenção não garante aprendizado. A equipe precisa transformar descoberta em correção, teste, automação ou documentação.
Observabilidade no ciclo de desenvolvimento
Defina sinais junto aos critérios de aceite. Uma nova API precisa de latência, erro e dependências; um job precisa de duração, atraso e último sucesso.
Valide em homologação se o trace atravessa componentes, se logs têm contexto e se alertas são testáveis.
Marque deploys nos dashboards e libere gradualmente. Feature flags ajudam a limitar exposição, mas também precisam aparecer na telemetria para comparar grupos.
Infraestrutura e regras de alertas podem ser versionadas conforme as práticas de Infraestrutura como Código.
Como controlar volume, cardinalidade e custo
Telemetria cresce com tráfego, número de serviços, rótulos e retenção. IDs de usuário, URL completa e valores quase únicos explodem séries de métricas.
Use atributos limitados nas métricas e deixe detalhes de alta cardinalidade para logs ou traces com controles adequados.
- Defina retenção diferente para sinais críticos e exploratórios.
- Faça amostragem de traces, preservando erros e casos lentos quando possível.
- Filtre eventos de baixo valor antes do armazenamento.
- Meça bytes ingeridos, séries ativas, consultas e custo por serviço.
- Remova dados sem uso comprovado em alerta, painel ou investigação.
Segurança e privacidade da telemetria
Logs e traces podem conter payloads, consultas, endereços, e-mails e tokens.
Classifique dados, minimize atributos, aplique mascaramento antes da exportação e restrinja acesso por ambiente e função. Proteja transporte, armazenamento e backups. Auditoria de consulta também é importante.
Não use segredo como identificador de correlação. Credenciais da própria plataforma devem seguir rotação e menor privilégio; o guia de gerenciamento de segredos detalha esse ciclo.
Erros comuns ao implementar observabilidade
- Coletar tudo sem objetivo: aumenta custo e esconde sinais importantes.
- Alertar cada recurso: cria fadiga e duplicação durante incidentes.
- Usar apenas médias: oculta usuários na cauda da latência.
- Não propagar contexto: impede conexão entre serviços e sinais.
- Ter dashboards sem dono: painéis ficam obsoletos após mudanças.
- Ignorar a plataforma de monitoramento: falhas silenciosas eliminam alertas.
- Expor dados sensíveis: transforma telemetria em risco de segurança.
- Medir infraestrutura sem jornadas: perde o impacto real ao usuário.
Plano de implementação em oito passos
- Escolha um serviço: relevante, conhecido e com dono definido.
- Mapeie jornadas: descreva o que significa sucesso para o usuário.
- Defina SLI e SLO: comece simples e documente a janela.
- Implemente sinais básicos: latência, tráfego, erros e saturação.
- Adicione contexto: ambiente, versão, serviço e correlação segura.
- Crie um dashboard: saúde primeiro, diagnóstico depois.
- Configure poucos alertas: impacto, responsável, runbook e rota testada.
- Revise incidentes e custos: melhore os sinais antes de expandir.
Aplicações gerenciadas por PM2, por exemplo, podem começar com disponibilidade, reinicializações, latência, erros e consumo, complementando o processo descrito no guia de PM2 em produção. O mesmo raciocínio se adapta a contêineres, funções e serviços gerenciados.
Como medir a maturidade da observabilidade
Observe tempo de detecção, tempo de mitigação, percentual de alertas acionáveis, incidentes descobertos por usuários, cobertura de SLO e frequência de alertas sem ação.
Meça também o tempo para responder a uma pergunta nova e a proporção de telemetria usada.
Maturidade não é quantidade de dashboards. É a capacidade de detectar impacto cedo, formar hipóteses com evidência, mitigar com segurança e converter incidentes em melhorias sustentáveis.
Perguntas frequentes
Observabilidade serve apenas para microsserviços?
Não. Um monólito, job, banco ou proxy também precisa revelar saúde e comportamento. Sistemas distribuídos aumentam a necessidade de traces e correlação, mas os princípios de experiência, sinais e alertas se aplicam a qualquer arquitetura.
É preciso coletar todos os dados?
Não. Colete dados que sustentem alertas, SLO, capacidade, segurança ou investigação. Amostragem, agregação e retenção seletiva controlam custo. Dados sem uso devem ser questionados.
Qual sinal deve ser implementado primeiro?
Para um serviço online, comece com métricas de latência, tráfego, erros e saturação, mais teste externo. Em seguida, estruture logs e adicione traces nas jornadas ou dependências que dificultam o diagnóstico.
OpenTelemetry armazena os dados?
Não como backend de observabilidade. Ele fornece APIs, SDKs, instrumentação, protocolo e Collector para produzir, processar e exportar telemetria. Os dados seguem para sistemas de armazenamento e análise compatíveis.
Conclusão
Observabilidade conecta sinais técnicos à experiência do usuário e à capacidade de investigação.
Monitoramento detecta condições; métricas, logs, traces e perfis contextualizados ajudam a entender por que elas aconteceram. SLI, SLO e alertas acionáveis mantêm o foco no impacto que realmente importa.
Comece por um serviço e uma jornada, não por uma ferramenta. Construa sinais confiáveis, teste o caminho do alerta, controle custo e privacidade e use cada incidente para melhorar o sistema.
A melhor plataforma é aquela que reduz surpresa, ruído e tempo de decisão sem criar outra infraestrutura impossível de operar.