Entendendo na Prática: o que e Observabilidade

O que e observabilidade?

E a capacidade de entender o estado interno de um sistema pelo que ele expoe.

Observabilidade e um conceito vindo da teoria de controle que, aplicado a sistemas de software, significa: dado o que o sistema emite (logs, métricas, traces), você consegue entender o que esta acontecendo dentro dele sem precisar adivinhar. Em sistemas distribuídos modernos, onde uma requisição pode passar por dezenas de microservicos, a observabilidade não e um luxo, e uma necessidade operacional. Sem ela, debugar um problema em produção se torna uma cacada no escuro. O objetivo não e apenas detectar quando algo esta errado, mas entender por que algo esta errado, qual foi o caminho exato da requisição que falhou e quais serviços foram afetados. Observabilidade e a fundação de qualquer operação confiável.

Os tres pilares da observabilidade

Logs, métricas e traces são complementares, cada um responde a perguntas diferentes.

A observabilidade repousa sobre tres tipos de dados. Logs são registros de eventos discretos, o que aconteceu, quando aconteceu, em qual serviço. São bons para investigar o que ocorreu em um momento específico. Métricas são medidas numericas ao longo do tempo, taxa de requisições, latência media, uso de CPU, número de erros. São boas para entender tendências e disparar alertas. Traces distribuídos rastreiam o caminho de uma requisição atraves de múltiplos serviços, mostrando onde o tempo foi gasto e onde a falha ocorreu. Os tres pilares se complementam: uma métrica de latência alta aponta que algo esta errado; os traces mostram em qual serviço a latência ocorreu; os logs detalham o erro específico naquele serviço.

Diferença entre monitoramento e observabilidade

Monitoramento responde perguntas conhecidas. Observabilidade permite fazer novas perguntas.

Monitoramento tradicional funciona com dashboards e alertas predefinidos: se a CPU passa de 80%, alerta. Se o tempo de resposta passa de 500ms, alerta. Isso funciona bem para problemas conhecidos, aqueles para os quais você ja sabe a pergunta. Observabilidade vai além: ela permite fazer perguntas que você não sabia que precisária fazer. Quando um problema novo aparece em produção, você precisa explorar os dados, correlacionar logs com traces, filtrar por usuário específico, por regiao geografica, por versão de API. Um sistema monitorado detecta que algo esta errado. Um sistema observável permite entender exatamente o que, onde e por que. Em sistemas distribuídos complexos, essa capacidade de exploração ad-hoc e o que separa horas de downtime de minutos.

OpenTelemetry

O padrão aberto que unifica instrumentação de logs, métricas e traces.

OpenTelemetry (OTel) e um projeto da CNCF que oferece um conjunto padronizado de APIs, SDKs e ferramentas para instrumentar aplicações e exportar logs, métricas e traces para qualquer backend, Jaeger, Prometheus, Datadog, Honeycomb ou qualquer outro. Antes do OTel, cada ferramenta de observabilidade tinha seu próprio SDK proprietário, o que tornava a troca de ferramenta um projeto grande. Com OTel, você instrumenta a aplicação uma vez e pode trocar o backend de observabilidade sem reescrever código. A instrumentação automática do OTel ja captura requisições HTTP, chamadas a banco de dados, chamadas a filas e outros frameworks populares sem código adicional. Hoje e o padrão de fato para observabilidade em sistemas cloud-native.

Distributed tracing com Jaeger

Rastrear o caminho de uma requisição revela onde a latência e os erros ocorrem.

Em uma arquitetura de microservicos, uma única requisição do usuário pode passar por API gateway, serviço de autenticação, serviço de produto, serviço de inventário e banco de dados antes de retornar uma resposta. Se a latência e alta, onde o tempo foi gasto? Se ocorreu um erro, em qual serviço? Distributed tracing responde essas perguntas. Cada serviço propaga um trace ID e um span ID nos headers das requisições. Cada operação cria um span com inicio, fim, atributos e eventual erro. Jaeger coleta esses spans e monta a árvore completa da requisição, mostrando visualmente o caminho percorrido, o tempo em cada serviço e onde ocorreram falhas. Isso transforma o debugging de sistemas distribuídos de uma atividade de horas em minutos.

Métricas com Prometheus e Grafana

Prometheus coleta métricas. Grafana as visualiza em dashboards e alertas.

Prometheus e um banco de dados de series temporais open source que coleta métricas por scraping, ele consulta periodicamente endpoints /metrics dos serviços instrumentados. As métricas são armazenadas localmente e consultadas com PromQL, uma linguagem de query poderosa para calcular taxas, percentis e agregações. Grafana se conecta ao Prometheus (e a dezenas de outras fontes) e cria dashboards visuais interativos. Um dashboard típico mostra taxa de requisições, latência no percentil 99, taxa de erros e uso de recursos. Alertmanager, componente do Prometheus, gerência alertas disparados por regras PromQL, agrupa notificações e as envia via Slack, PagerDuty ou email. A combinação Prometheus + Grafana + Alertmanager e o stack de monitoramento de métricas mais adotado no mundo open source.

Estruturando logs para observabilidade

Logs em JSON com campos padronizados são a base da observabilidade.

Logs de texto livre como "Erro ao processar pedido: connection timeout" são difíceis de processar automaticamente. Logs estruturados em JSON com campos padronizados são fundamentais para observabilidade efetiva. Um log de qualidade contem: timestamp em ISO 8601, nível de severidade, nome do serviço, trace ID (para correlação com traces), user ID quando relevante, e a mensagem com contexto. Com esse formato, e possível filtrar por trace ID para ver todos os logs de uma requisição específica, agregar erros por serviço, criar alertas baseados em padrões de logs e correlacionar logs com spans do trace distribuído. Ferramentas como Serilog (.NET), Logback (Java) e Winston (Node.js) facilitam a emissão de logs estruturados com nível mínimo de configuração.

SLI e SLO na prática

Métricas de confiabilidade do ponto de vista do usuário definem o que importa medir.

SLI (Service Level Indicator) e uma métrica que mede a experiência real do usuário: porcentagem de requisições com latência abaixo de 200ms, porcentagem de requisições bem-sucedidas, disponibilidade do serviço. SLO (Service Level Objective) e a meta para esse SLI: 99.9% das requisições devem ter latência abaixo de 200ms. O conceito de error budget, introduzido pelo SRE do Google, define que se o SLO e 99.9%, o time tem 0.1% de budget para usar em indisponibilidade, seja por incidentes ou por deploys de risco. Quando o budget e consumido, novos deploys são pausados até a confiabilidade ser restaurada. SLI e SLO transformam a conversa sobre qualidade de subjetiva ("o sistema esta lento") para objetiva ("o P99 de latência passou de 200ms nas ultimas 2 horas").

Exemplos de debugging com observabilidade

Como traces, métricas e logs se combinam para resolver problemas em produção.

Cenário real: alerta de latência alta no serviço de checkout. O engenheiro abre o dashboard do Grafana e ve que o P99 de latência do checkout passou de 150ms para 2.3 segundos há 20 minutos. Abre o Jaeger, filtra por traces do checkout com mais de 1 segundo e ve que o tempo esta concentrado na chamada ao serviço de inventário. Abre os logs do serviço de inventário filtrados pelo trace ID de um trace lento e ve "database connection pool exhausted". Consulta a métrica de conexões ativas no banco e confirma que o pool esta no limite. Causa raiz identificada em menos de 5 minutos. Sem observabilidade, esse debugging levária horas de SSH em servidores, leitura manual de logs e muito chute. Esse e o valor concreto da observabilidade bem implementada.

Resumo final

Observabilidade e o que separa sistemas que você opera dos que operam você.

Observabilidade e um investimento que se paga na primeira vez que um problema crítico em produção e resolvido em minutos em vez de horas. Os tres pilares, logs, métricas e traces, cobrem diferentes dimensões do comportamento do sistema e são mais poderosos quando correlacionados. OpenTelemetry tornou a instrumentação mais acessível e portável. Prometheus e Grafana oferecem monitoramento de métricas de nível produção sem custo de licença. SLI e SLO colocam a experiência do usuário no centro das decisões de qualidade. Começar não exige implementar tudo de uma vez: logs estruturados e métricas básicas de RED (Rate, Errors, Duration) ja dao uma visibilidade enorme sobre sistemas que antes eram caixas pretas.