A diferença entre monitoramento e observabilidade em sistemas distribuídos

O monitoramento clássico é construído em torno de perguntas conhecidas de antemão: se o servidor está no ar, se a CPU está acima de 80 por cento, se o disco está enchendo, se o job noturno terminou. Um operador escolhe um sinal, define um limite e gera um alerta quando ele é ultrapassado. Para poucos servidores executando um monólito, isso funciona bem, porque a lista do que pode dar errado é curta e quem está de plantão a conhece de cor.

A limitação é que cada verificação embute uma previsão. Quando a falha é uma que ninguém previu, como uma dependência downstream lenta, uma tempestade de novas tentativas ou um cache que tecnicamente está no ar mas retorna dados desatualizados, os painéis continuam verdes enquanto os clientes reclamam. O monitoramento continua necessário, mas deixa de ser suficiente quando o sistema fica maior do que o modelo mental de uma única pessoa.

Leve a mesma função de negócio para uma dúzia de serviços com uma fila de mensagens no meio e três coisas mudam. Primeiro, uma única requisição de usuário passa a envolver muitos processos em muitos hosts, e nenhum arquivo de log conta a história inteira. Segundo, as falhas se tornam parciais: uma região, um locatário ou um caminho de código fica lento enquanto o agregado parece saudável. Terceiro, o sistema muda muitas vezes por dia, e a referência de ontem já não vale.

Observabilidade é a propriedade de conseguir entender o estado interno do sistema a partir dos dados que ele emite, sem publicar código novo para fazer uma nova pergunta. Na prática, significa coletar telemetria rica e de alta cardinalidade (qual cliente, qual endpoint, qual versão, qual região) e conseguir recortá-la sob demanda. A pergunta deixa de ser se o sistema está no ar e passa a ser quais usuários estão sentindo lentidão, desde quando e o que mudou.

Um objetivo de nível de serviço (SLO) é uma meta para uma medida percebida pelo usuário: por exemplo, 99,9 por cento das requisições de checkout concluídas com sucesso em até 500 milissegundos, medidas ao longo de 30 dias. O percentual e a janela são definidos pela organização; o essencial é que o SLO descreve o que os usuários vivenciam, e não o que um host reporta.

Um SLO define um orçamento de erros, a quantidade de falhas que pode ser absorvida na janela, e com ele um modelo de alertas diferente. Em vez de acionar o plantão quando a CPU ultrapassa uma linha, a equipe é acionada quando o orçamento está sendo consumido rápido demais para durar a janela inteira (um alerta de taxa de consumo). Consumos lentos viram chamados para o próximo dia útil; consumos rápidos acionam o engenheiro de plantão. Essa única mudança elimina a maior parte dos alertas que disparam sem que ninguém precise agir.

Os SLOs também dão à engenharia e ao negócio uma linguagem comum. Se o orçamento está saudável, a equipe pode entregar mais rápido; se está sendo consumido, a equipe investe em confiabilidade. Um gráfico de CPU não sustenta essa conversa.

A falha mais comum dos programas de monitoramento é o excesso de alertas, e não a falta. Quando uma escala recebe dezenas de acionamentos por semana e a maioria não exige nenhuma ação, as pessoas deixam de lê-los, e o que realmente importa se perde no ruído. Todo alerta deve passar por um teste simples: uma pessoa precisa poder fazer algo a respeito imediatamente. Se não for o caso, o lugar dele é um painel ou um relatório diário, e não um acionamento.

Trate o conjunto de alertas como código sob revisão. Cada alerta tem um responsável, um link para o runbook e uma razão de existir; alertas que disparam sem ação durante um mês são excluídos ou rebaixados. Meça a própria escala: acionamentos por semana, acionamentos fora do horário de trabalho, tempo até o reconhecimento. Uma escala de plantão saudável é sinal de um sistema saudável, e uma escala sobrecarregada indica claramente onde investir.

Sistemas distribuídos acrescentam mais um requisito: os alertas devem trazer contexto. Um acionamento que diz “error rate high on payments-api” é uma tarefa de investigação; um acionamento com links para o SLO afetado, a implantação mais recente e o endpoint com mais falhas é uma decisão.

Os dados de observabilidade têm um custo, e a conta costuma chegar depois que o hábito já se formou. Os dois fatores são o volume (bytes de logs e spans por requisição, multiplicados pelo tráfego) e a cardinalidade (o número de combinações distintas de rótulos em uma métrica). Uma métrica rotulada com o ID do usuário ou o ID da requisição gera uma nova série temporal para cada valor e sobrecarrega qualquer armazenamento de métricas.

Padrões sensatos já resolvem muita coisa. Mantenha identificadores de alta cardinalidade em traces e logs estruturados, e não em labels de métricas. Faça amostragem de traces, preservando todos os erros e requisições lentas e apenas uma fração das normais. Defina a retenção por tipo de sinal: métricas por um ano com resolução reduzida, logs por semanas, traces por dias, com uma camada de arquivamento para tudo o que a conformidade exigir. Revise mensalmente as maiores fontes de volume de logs; uma única instrução de debug detalhada em um caminho crítico pode responder por boa parte da fatura.

O objetivo não é coletar tudo, e sim conseguir responder rapidamente à próxima pergunta ainda desconhecida, a um custo que a organização esteja disposta a continuar pagando.