O que é observabilidade? Logs, métricas e traces explicados

O que é observabilidade? É a capacidade de descobrir o que um sistema está fazendo, e por quê, usando apenas os dados que ele emite: logs, métricas e traces. Se o monitoramento avisa que algo quebrou, a observabilidade permite fazer a pergunta seguinte: onde, para quem e desde quando. Se você vive em planilhas, já faz uma versão pequena disso toda vez que rastreia um número estranho até a linha de origem.

A versão de um minuto para quem vive em planilhas

Imagine uma planilha de receita mensal em que o total parece errado. Um painel que diz "o total está errado" é monitoramento. Conseguir filtrar por região, por dia e por produto, e descobrir a importação que duplicou 400 linhas, isso é observabilidade.

Equipes de software enfrentam o mesmo problema com sistemas no ar. Uma página de checkout fica lenta. Um alerta dispara. Agora alguém precisa descobrir qual serviço, qual segmento de clientes e qual deploy causou aquilo. Os dados que tornam isso possível se chamam telemetria, e a capacidade de usá-los bem é o que as pessoas querem dizer com observabilidade.

O Biscuit tem uma versão disso também. Ele não precisa que alguém diga que a bolinha sumiu. Ele precisa refazer o caminho até o último lugar em que ela foi vista.

Monitoramento x observabilidade: problemas conhecidos e surpresas

O monitoramento observa aquilo que você decidiu observar com antecedência. CPU acima de 90%, taxa de erro acima de 2%, uma página que para de responder. Você escreve a regra, e a ferramenta dispara quando a regra é quebrada.

A observabilidade serve para os problemas para os quais você não escreveu regra nenhuma. O projeto OpenTelemetry descreve a observabilidade como a forma de entender um sistema por fora, sem conhecer o funcionamento interno, o que ajuda com os problemas que você nem sabia que podiam existir.

Não pense que uma substitui a outra. O monitoramento é o detector de fumaça. A observabilidade é a planta da casa e as imagens da câmera que você puxa depois. Você precisa das duas.

Logs, métricas e traces: os três ingredientes brutos

Quase toda explicação chega aos mesmos três sinais. Veja cada um em termos de planilha.

Logs são mensagens com data e hora sobre eventos individuais. Numa planilha, é uma linha por evento: horário, usuário, ação, resultado. Trazem o maior detalhe e ocupam mais espaço.

Métricas são números agregados ao longo do tempo, como taxa de erro, requisições por minuto ou memória usada. Numa planilha, é a sua aba de resumo. São baratas de guardar e rápidas de transformar em gráfico, mas não dizem qual requisição específica falhou.

Traces acompanham uma requisição enquanto ela passa por vários serviços, com o tempo gasto em cada etapa. Numa planilha, pense num ID de pedido que você segue por cinco abas, anotando quanto tempo ele ficou parado em cada uma.

A regra prática: as métricas dizem que algo está errado, os traces dizem mais ou menos onde, e os logs dizem o detalhe. Veja o que isso dá numa célula de verdade, em um minuto.

Você tem 5,000 linhas de log num arquivo: um exemplo prático no Sheets

Digamos que você exportou 5,000 linhas de um log de aplicação para o Google Sheets. A coluna A tem o carimbo de data e hora, a B o nome do serviço, a C o código de status e a D o tempo de resposta em milissegundos. Funciona no Excel e no Sheets, salvo indicação em contrário.

Primeiro, a taxa de erro, uma métrica clássica:

=COUNTIF(C2:C5001, ">=500") / COUNTA(C2:C5001)

• O intervalo é C2:C5001, os códigos de status.

• O critério ">=500" conta todos os erros do servidor.

• Dividir por COUNTA dá a fração do total de requisições. Formate a célula como porcentagem.

Isso é monitoramento: um número, um limite. Agora a parte da observabilidade. Qual serviço é o responsável?

=QUERY(A1:D5001, "select B, count(C) where C >= 500 group by B order by count(C) desc", 1)

Esta só funciona no Sheets, porque o QUERY não tem equivalente no Excel. Os argumentos:

• Os dados são A1:D5001, com o cabeçalho incluído.

• O texto é uma consulta parecida com SQL: contar os erros por serviço, do maior para o menor.

• O último 1 indica que há uma linha de cabeçalho.

No Excel 365, a mesma resposta sai com outra receita:

=LET(s, FILTER(B2:B5001, C2:C5001>=500), u, UNIQUE(s), HSTACK(u, COUNTIF(s, u)))

Isso exige Excel 365, porque HSTACK só existe nas versões por assinatura. FILTER e UNIQUE já estão no Excel 2021, mas o Excel 2016 não tem nenhuma das três. Para versões mais antigas, uma tabela dinâmica resolve melhor.

E para as requisições lentas, o percentil 95 é mais honesto que a média:

=PERCENTILE(D2:D5001, 0.95)

Se o tempo médio de resposta é 180 ms, mas o percentil 95 é 2,400 ms, um em cada vinte usuários está tendo um dia ruim. A média esconde isso, e é exatamente essa armadilha que as ferramentas de observabilidade tentam ajudar você a evitar.

O Biscuit já buscou isso para você, se a fórmula é a parte que você sempre esquece. O Formula.dog transforma uma descrição em linguagem comum em uma dessas fórmulas.

Onde a observabilidade aparece num dia de trabalho normal

Você não precisa rodar servidores para esbarrar nela. Um líder de suporte que pergunta "por que os chamados dobraram na terça?" está fazendo isso. Também faz um analista financeiro que rastreia uma variação até uma única nota fiscal de fornecedor, ou alguém de operações que descobre que uma importação noturna ignorou um arquivo sem avisar.

Em software, as mesmas perguntas ficam mais difíceis porque os sistemas são distribuídos. Um clique num botão pode passar por um gateway de API, um serviço de autenticação, um banco de dados e um provedor de pagamento. Quando falha, a mensagem de erro que você vê raramente é o ponto onde tudo começou. Um trace mostra a cadeia inteira, com o elo lento ou quebrado destacado, para que ninguém precise adivinhar.

Três termos aparecem o tempo todo, então aqui vão em palavras simples:

• Instrumentação é adicionar o código que emite a telemetria. Pense nisso como acrescentar uma coluna de data e de ID a um relatório que nunca teve uma.

• Cardinalidade é quantos valores diferentes um campo pode assumir. Região tem baixa cardinalidade, ID de usuário tem altíssima. Campos de alta cardinalidade respondem às perguntas mais precisas e custam mais para manter.

• SLO (objetivo de nível de serviço) é uma meta que você se compromete a cumprir, como "99.5% dos checkouts terminam em menos de dois segundos". Transforma uma preocupação vaga em um número que você pode acompanhar.

Por que uma pilha de painéis não é observabilidade

Aqui vai a opinião que incomoda os fornecedores: ter os três sinais não significa ter observabilidade. Se as métricas ficam numa ferramenta, os logs em outra e os traces numa terceira, alguém precisa alinhar tudo na mão às 2 da manhã. É o equivalente a três pastas de planilhas sem uma coluna de ID em comum.

O teste é simples. Quando algo inesperado quebra, você consegue fazer uma pergunta nova sobre os seus dados sem subir código novo? Se a resposta for "precisaríamos adicionar logs e fazer deploy de novo", você tem monitoramento com passos extras.

Duas coisas fazem diferença na prática:

• Contexto em cada evento. Cada linha de log carrega um ID de requisição, o nome do serviço e a versão, para que você possa agrupar e filtrar depois. É a coluna de ID que você gostaria que toda exportação tivesse.

• Detalhe guardado por tempo suficiente. Os dados de alta cardinalidade (IDs de usuário, IDs de pedido) são onde as respostas se escondem, e também são o que faz a conta subir.

As ferramentas que as pessoas usam de fato e o que cada uma custa

Você não precisa comprar nada para entender a ideia, mas vale conhecer o mercado.

A OpenTelemetry é o padrão aberto para produzir telemetria, e não um lugar para guardar ou visualizar os dados. Você instrumenta uma vez e envia os dados para onde quiser.

O Grafana Cloud é construído sobre padrões abertos e tem um plano gratuito de 10,000 séries de métricas ativas e 50 GB por mês de logs, traces e profiles. Também dá para hospedar a pilha open source por conta própria, ao custo de montar Prometheus, Loki e Tempo sozinho.

O Datadog é a opção pronta para uso: instale o agente, tenha painéis funcionando em minutos, com infraestrutura, APM e logs num só lugar. O problema está na cobrança. O preço por host (em torno de $15 por host por mês só para infraestrutura), somado às cobranças separadas de logs e de métricas customizadas, pode subir rápido depois de cerca de 50 hosts, e não existe plano gratuito permanente.

O New Relic fica no meio em termos de preço: 100 GB de ingestão de dados por mês gratuitos, depois $0.40 por GB, com um usuário completo da plataforma incluído.

Vale o investimento se você tem um time de plataforma pequeno e nenhuma vontade de rodar uma infraestrutura para monitorar a sua infraestrutura. Não vale se você tem dois servidores e um desenvolvedor. Um bom formato de log e as fórmulas acima já levam você bem longe.

O que fazer na segunda-feira se você não é engenheiro

Talvez você nunca toque num trace. Mas o raciocínio de observabilidade se aplica bem a quem reporta números para viver.

1. Adicione um ID em toda exportação. Uma coluna que sirva para cruzar dados vale mais do que qualquer fórmula esperta.

2. Guarde as linhas brutas. Não cole valores por cima da aba de detalhe. Resumos são métricas, linhas brutas são logs.

3. Defina por escrito o que é "normal". Um limite que você nunca definiu não consegue disparar.

4. Faça a terceira pergunta. "A receita caiu" é o alerta. "Caiu onde?" é a métrica. "Caiu por causa de quais linhas?" é observabilidade.

Se você fizer isso, a próxima total estranha na sua planilha vai levar dez minutos para explicar, em vez de uma tarde inteira. Bom menino, planilha.

As versões curtas das dúvidas mais comuns estão no FAQ abaixo. Se você lembrar de uma coisa só: observabilidade não é um produto que se compra. É o quanto os dados que o seu sistema emite permitem responder perguntas que você não planejou.