Monitoramento e Observabilidade: Saúde de Sistemas em Tempo Real

Quando um sistema falha às 3 da manhã, você quer saber o quê, onde e porquê em segundos — não em horas. Monitoramento e observabilidade são as práticas que transformam caos em clareza, permitindo que times entendam e resolvam problemas antes que usuários percebam.

Monitoramento vs. Observabilidade

Monitoramento pergunta: "o sistema está saudável?". Você define métricas e alertas conhecidos de antemão. Funciona bem para problemas previsíveis, mas falha quando algo inesperado acontece.

Observabilidade pergunta: "por que o sistema está se comportando assim?". Em vez de prever todos os problemas, você instrumenta o sistema para emitir sinais ricos e depois explora esses sinais para entender qualquer comportamento — esperado ou não.

Os Três Pilares da Observabilidade

Métricas

Métricas são medidas numéricas ao longo do tempo. Elas respondem a perguntas sobre tendências, volumes e saúde geral. Exemplos: latência de requisições, uso de CPU, taxa de erros, número de usuários ativos.

Boa prática: use histogramas para latência em vez de médias. O percentil 99 (p99) mostra a experiência dos usuários mais afetados, enquanto a média esconde outliers.

Logs

Logs são registros detalhados de eventos discretos. Eles respondem "o que aconteceu" em um momento específico. Logs estruturados (JSON) são preferíveis a texto livre porque permitem buscas e filtros eficientes.

Boa prática: inclua correlation IDs em todos os logs de uma mesma requisição. Isso permite rastrear o caminho de uma solicitação através de múltiplos serviços.

Traces (Rastreamento Distribuído)

Traces acompanham uma requisição do início ao fim, passando por todos os serviços e componentes que ela toca. Mostram onde o tempo foi gasto e quais serviços falharam no caminho.

Em arquiteturas de microserviços, traces são indispensáveis. Sem eles, diagnosticar lentidão é como encontrar uma agulha em dezenas de haystacks.

Ferramentas do Mercado

O ecossistema de observabilidade é vasto. A escolha depende de orçamento, escala e preferência por managed vs. self-hosted.

OpenTelemetry: O Padrão Aberto

OpenTelemetry (OTel) é um projeto da Cloud Native Computing Foundation que padroniza como instrumentar aplicações para métricas, logs e traces. Em vez de ficar preso a um vendor, você instrumenta uma vez e exporta para qualquer backend.

// Exemplo básico de instrumentação OpenTelemetry em Node.js
import { NodeSDK } from "@opentelemetry/sdk-node";
import { getNodeAutoInstrumentations } from "@opentelemetry/auto-instrumentations-node";
import { PrometheusExporter } from "@opentelemetry/exporter-prometheus";
import { JaegerExporter } from "@opentelemetry/exporter-jaeger";

const sdk = new NodeSDK({
  metricReader: new PrometheusExporter({ port: 9091 }),
  traceExporter: new JaegerExporter({ endpoint: "http://jaeger:14268/api/traces" }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

Alertas Inteligentes: Menos é Mais

O erro mais comum em monitoramento é alertar demais. Quando tudo gera notificação, nada é urgente. Alertas devem ser acionáveis, precisos e raros.

• Alerte sobre sintomas que usuários sentem (latência alta, erros visíveis), não sobre causas (CPU alta pode ser normal).
• Use janelas de tempo: um spike de 30 segundos não merece acordar ninguão à noite.
• Evite alertas de threshold fixo em métricas sazonais. Use detecção de anomalia quando possível.
• Tenha runbooks: todo alerta deve ter um link para instruções de investigação e resolução.
• Página apenas o que quebra negócio. Tudo mais pode ser um ticket para o dia seguinte.

SLIs, SLOs e SLAs

Terminologia do Google SRE que ajuda a definir o que "sistema saudável" significa de forma mensurável e acionável.

SLOs são internos. SLAs são externos e geralmente mais conservadores. Não prometa em SLA o que você não consegue consistentemente manter em SLO.

Dashboards que Realmente Ajudam

Dashboards bonitos não são dashboards úteis. Um bom dashboard responde uma pergunta específica em um único olhar. Evite o antipadrão da "tela de status" com dezenas de gráficos irrelevantes.

• Dashboard de saúde: 4-6 métricas que mostram se o sistema está bem agora.
• Dashboard de capacidade: previsão de quando recursos vão esgotar.
• Dashboard de negócio: métricas de usuário (sign-ups, conversão) correlacionadas com técnicas.
• Dashboard de investigação: drill-down detalhado para quando algo quebra.

Conclusão

Observabilidade não é sobre coletar mais dados — é sobre fazer perguntas melhores. Comece instrumentando o básico: latência, taxa de erro e throughput. Adicione logs estruturados com correlation IDs. Depois, trace requisições entre serviços.

O objetivo final é reduzir o tempo médio de detecção (MTTD) e o tempo médio de resolução (MTTR). Quanto mais rápido você descobre e entende um problema, menos usuários são afetados. E em operações de software, isso é tudo.

Perguntas frequentes

Fontes consultadas

• OpenTelemetry Documentation
• Google SRE Book — Monitoring Distributed Systems
• The Three Pillars of Observability (Honeycomb)