Quando um sistema falha silenciosamente em produção, a diferença entre 20 minutos e 20 horas de incidente está na qualidade do que você consegue enxergar e em onde você escolheu olhar.
* Este artigo é baseado em um incidente real ocorrido em novembro de 2025 em uma grande distribuidora de energia elétrica brasileira. Detalhes de identificação foram omitidos a pedido da empresa.
Observabilidade não é monitoramento
Essa distinção parece semântica. Não é.
Monitoramento responde a uma pergunta definida com antecedência: “esse componente está de pé?” Você configura um threshold, o sistema cruza esse threshold, o alerta dispara. Funciona bem para falhas óbvias e previsíveis.
Observabilidade responde a perguntas que você ainda não sabe que vai precisar fazer. Em vez de alertar apenas quando algo quebra, ela permite reconstruir o comportamento interno do sistema a partir dos sinais que ele emite: métricas, logs e traces. A diferença prática: com monitoramento, você descobre que o sistema caiu. Com observabilidade, você descobre por que e onde, antes ou durante a queda.
Essa distinção tem consequências diretas em como sistemas distribuídos são operados. E o incidente que a concessionária enfrentou em novembro de 2025 é um exemplo preciso de quando ela importa.
O contexto: sistemas distribuídos em infraestrutura crítica
A empresa em questão opera a distribuição de energia elétrica em múltiplos estados brasileiros. Por trás disso existe uma arquitetura de sistemas que precisa funcionar em tempo real, com tolerância mínima a falhas, porque as consequências de uma falha não são degradação de experiência do usuário, são fios partidos sem equipe alocada e eletricistas operando sem visibilidade do estado da rede.
O pipeline central de operação funciona assim: reclamações de clientes chegam via SCADA (o sistema de supervisão e controle que monitora a rede elétrica em tempo real, operando na rede Tecnologia Operacional (OT), tecnologia operacional, isolada da TI convencional). Do SCADA, os eventos trafegam via Kafka, uma plataforma de mensageria distribuída, até o sistema de geração de ordens de serviço, que despacha os eletricistas para campo.
Cada elo desse pipeline é um ponto potencial de falha. E em sistemas distribuídos, falhas raramente gritam, elas sussurram, degradando silenciosamente até que o impacto se torna impossível de ignorar.
Foi exatamente isso que aconteceu durante a tempestade severa de novembro de 2025 no Centro-Oeste brasileiro, quando 150 milhões de registros de falta de energia inundaram o sistema em questão de minutos.
O problema central da observabilidade: limites ocultos
Em qualquer sistema distribuído com algum histórico de operação, existem restrições de concepção que nunca foram encontradas em produção. Limites de tamanho de payload, timeouts de integração, capacidades máximas de filas, parâmetros definidos em um contexto de carga que nunca antecipou o pior cenário real.
Esses são os limites ocultos: invisíveis nos dashboards de CPU e memória, ausentes nos alertas de latência, inexistentes nos testes de carga que nunca simularam aquela combinação específica de volume, velocidade e tamanho de dado.
Nesse incidente, o limite oculto era de 1MB por mensagem no processador de logs, o componente responsável por receber os eventos do Kafka e encaminhá-los para o sistema de Ordem de Serviço (OS). Em condições normais, as mensagens nunca chegavam perto desse limite. Com 150 milhões de registros simultâneos, o tamanho das mensagens ultrapassou o threshold. O processador parou de aceitar. O Kafka continuava recebendo. O sistema de OS parou de gerar ordens.
Nenhum alerta de CPU disparou. Nenhum alerta de memória. O sistema parecia saudável, e estava paralisado.
Esse é o problema que a observabilidade existe para resolver.
APM: onde a visibilidade se torna diagnóstico
Application Performance Monitoring (APM) é a camada de observabilidade que acompanha o comportamento de aplicações em tempo de execução, rastreando o fluxo de requisições entre serviços, medindo latência por componente e correlacionando anomalias de desempenho com pontos específicos do código e da infraestrutura.
A diferença entre APM e monitoramento tradicional está na granularidade e na correlação. Um monitor de serviço diz “este serviço está lento”. Um APM diz “este endpoint específico, neste serviço, está acumulando fila desde às 14h32, e o throughput caiu 94% após esse horário”.
Na operação em questão, o Datadog APM estava configurado com monitores individuais por endpoint, uma decisão de configuração que muitos times evitam por reduzir a simplicidade operacional. Em um ambiente com operação em múltiplos estados e uma planta extensa, a preferência comum seria agrupar endpoints para diminuir o volume de alertas.
Mas foi exatamente essa granularidade que tornou o diagnóstico possível.
Quando o processador de logs travou, o APM identificou a anomalia em um ponto preciso do pipeline: o throughput de consumo havia parado em um endpoint específico, enquanto o volume de entrada no Kafka permanecia constante. Esse delta, mensagens entrando, mensagens não saindo, foi o sinal que direcionou a investigação.
Sem essa visibilidade granular, o time estaria procurando o problema em todo o sistema simultaneamente. Com ela, foi direto ao componente.
A armadilha do agrupamento: conforto operacional versus capacidade de diagnóstico
Vale aprofundar esse ponto, porque ele é uma das decisões de configuração mais comuns, e mais consequentes, em times de SRE e plataforma.
Agrupar endpoints em um único monitor reduz o número de alertas ativos. Em ambientes grandes, isso parece razoável: menos ruído, mais foco. O problema é que o agrupamento transforma o monitor em uma média, e médias escondem anomalias localizadas.
Imagine um serviço com 20 endpoints. Dezoito estão operando normalmente. Dois estão com throughput zero. A média do grupo pode ainda parecer saudável. O monitor não dispara. O problema cresce.
A decisão de monitorar por endpoint individual é uma troca consciente: mais alertas potenciais em troca de mais capacidade de localização. Em sistemas onde a localização do problema define a velocidade de resposta, especialmente em infraestruturas críticas com impacto físico real, essa troca geralmente vale.
A configuração certa de APM não é aquela que gera menos alertas. É aquela que gera o alerta certo, no momento certo, com informação suficiente para agir.
Observabilidade como prática, não como ferramenta
Um dos erros mais comuns na adoção de ferramentas de observabilidade é tratar o “Discovery” automático, a capacidade que ferramentas como Datadog têm de mapear automaticamente serviços e dependências, como o fim da jornada.
O Discovery é um ponto de partida. Ele entrega uma visão do que existe. Não entrega uma visão do que importa para o negócio.
Calibrar um ambiente de observabilidade para o contexto específico de uma operação exige que times diferentes, negócio, fábrica de software, sustentação, monitoração, estejam alinhados sobre o que precisa ser visível e por quê. O que deve disparar um alerta num sistema de gestão de ordens de serviço é diferente do que deve disparar em uma API de e-commerce. O volume esperado numa segunda-feira de novembro é diferente do volume esperado durante uma tempestade severa.
Esse alinhamento não é um evento único. É uma prática contínua. O que faz sentido monitorar hoje pode não ser o mais relevante em seis meses, porque o sistema evoluiu, porque o negócio mudou, porque um incidente revelou um ponto cego que ninguém havia antecipado.
Observabilidade é orgânica. E só funciona quando todos os times se sentem donos dela, não apenas usuários da licença.
O que esse incidente consolida sobre APM e observabilidade
O case não é sobre uma tempestade. É sobre o que fica visível e o que permanece oculto, dependendo de como um time escolhe instrumentar seus sistemas.
Três princípios saem daqui e valem para qualquer ambiente em produção:
Monitore com granularidade onde o negócio exige precisão. Em sistemas distribuídos, a localização do problema é tão importante quanto sua existência. Monitores individuais por endpoint custam mais atenção operacional, mas entregam diagnóstico cirúrgico quando o incidente acontece.
Mapeie seus limites antes que a produção os descubra. Todo sistema tem restrições de concepção que nunca foram testadas em escala real. Testes de carga realistas, revisões de design com fornecedores e SLOs definidos por componente são formas de trazer esses limites à superfície antes do incidente, não durante.
APM não substitui alinhamento entre times. A ferramenta certa, configurada pelo time certo, calibrada para o negócio certo, isso é o que transforma telemetria em capacidade de resposta. Nenhuma licença faz isso sozinha.
O próximo evento de alta demanda vai acontecer. A questão não é se o sistema vai ser testado, é se ele vai ser testado com você no controle ou à mercê do volume.
Fernando de Oliveira
Analista SRE