Monitoramento e observabilidade: práticas recomendadas de APM, registro e alertas

Empresas com práticas maduras de observabilidade resolvem incidentes 69% mais rápido, de acordo com o relatório State of Observability do Splunk. O monitoramento informa que algo está quebrado. A observabilidade informa por que está quebrado e onde procurar. A diferença entre combater todos os problemas de produção durante horas e resolvê-los em minutos depende de quão bem você instrumenta seus sistemas, estrutura seus logs e projeta seus alertas.

Principais conclusões

• Os três pilares da observabilidade – métricas, logs e rastreamentos – respondem a diferentes perguntas e trabalham juntos para fornecer uma compreensão completa do sistema
• Alerta sobre sintomas (impacto voltado ao usuário) e não sobre causas (métricas internas) para reduzir a fadiga de alertas e detectar novos modos de falha
• O registro JSON estruturado com IDs de correlação permite pesquisar entre serviços e reconstruir fluxos de solicitação
• SLOs (Objetivos de Nível de Serviço) transformam o monitoramento de "algo está quebrado" para "estamos cumprindo nossos compromissos com os usuários"

---

Os três pilares da observabilidade

A observabilidade baseia-se em três tipos de dados complementares. Cada pilar responde a diferentes perguntas sobre o comportamento do seu sistema.

Métricas

Métricas são medidas numéricas coletadas em intervalos regulares. Eles respondem a perguntas do tipo “o que está acontecendo”: quantas solicitações por segundo? Qual é o tempo médio de resposta? Quanta memória está em uso?

Características:

• Agregado e compacto – milhões de eventos compactados em contadores de série temporal
• Barato para armazenar – dados de tamanho fixo, independentemente do volume de tráfego
• Ideal para painéis e alertas
• Contexto limitado: você sabe que o tempo de resposta aumentou, mas não sabe quais solicitações específicas estão lentas

Principais tipos de métricas:

• Contador - valor crescente monotonicamente (total de solicitações, total de erros)
• Gauge – valor que sobe e desce (uso atual da CPU, conexões ativas)
• Histograma – distribuição de valores (percentis de tempo de resposta, tamanhos de carga útil)
• Resumo -- percentis pré-calculados no lado do cliente

Registros

Logs são registros de texto com carimbo de data e hora de eventos discretos. Eles respondem a perguntas “o que aconteceu”: Que mensagem de erro o usuário viu? Quais parâmetros foram passados ​​para a função com falha? Qual era o estado do sistema quando o problema ocorreu?

Características:

• Contexto rico – detalhes arbitrários sobre eventos individuais
• Caro em escala: sistemas de alto tráfego geram gigabytes de logs por hora
• Pesquisável - encontre eventos específicos com pesquisa de texto completo
• Requer estrutura – linhas de log não estruturadas são difíceis de analisar e correlacionar

Traços

Os rastreamentos seguem uma única solicitação em vários serviços. Eles respondem às perguntas “onde está o tempo gasto”: Qual chamada de serviço é lenta? Onde o caminho da solicitação diverge? Qual consulta de banco de dados é o gargalo?

Características:

• Mostrar causalidade - relações pai-filho entre operações
• Revelar o comportamento do sistema distribuído – latência entre limites de serviço
• Amostragem necessária em escala – rastrear cada solicitação é caro
• Essencial para microsserviços: sem rastros, a depuração de fluxos multisserviços é um trabalho de adivinhação

---

Ecossistema de ferramentas de observabilidade

Escolhendo uma pilha

Para a maioria das empresas em crescimento, recomendamos começar com:

1. Sentry para rastreamento de erros – detecta exceções com rastreamentos completos de pilha, mapas de origem e rastreamento de lançamento
2. Prometheus + Grafana para métricas – ecossistema de integração extenso, de código aberto, testado em batalha
3. Registro estruturado para um serviço gerenciado – Datadog Logs, AWS CloudWatch ou Grafana Loki, dependendo do seu provedor de nuvem
4. OpenTelemetry para instrumentação: padrão neutro de fornecedor que funciona com qualquer back-end

Para equipes que desejam um único fornecedor, o Datadog oferece a melhor experiência completa, mas com custos significativos em escala. A pilha de código aberto do Grafana (Prometheus, Loki, Tempo) oferece recursos equivalentes com menor custo de licenciamento, mas maior carga operacional.

---

Práticas recomendadas de registro estruturado

Linhas de log não estruturadas como Error processing order 12345 for user [email protected] são legíveis por humanos, mas hostis à máquina. Os logs JSON estruturados permitem pesquisar, filtrar, agregar e alertar em campos específicos.

Estrutura de registro

Cada entrada de log deve incluir:

IDs de correlação

Um ID de correlação é um identificador exclusivo gerado no início de cada solicitação e passado para cada chamada de serviço downstream, consulta de banco de dados e trabalho em segundo plano. Ao investigar um problema, a pesquisa por ID de correlação mostra todas as entradas de log relacionadas a essa solicitação específica em todos os serviços.

Implementação: Gere um UUID no gateway da API ou no balanceador de carga, passe-o no cabeçalho X-Request-ID e inclua-o em cada entrada de log. No NestJS, use um middleware que extraia ou gere o ID de correlação e o armazene no contexto de armazenamento local assíncrono.

Níveis de registro

Use níveis de log de forma consistente:

• DEBUG – informações de diagnóstico detalhadas, desativadas na produção, a menos que esteja depurando ativamente
• INFO – eventos comerciais significativos (pedido feito, usuário registrado, pagamento processado)
• AVISO -- situações inesperadas que o sistema tratou, mas que devem ser investigadas (nova tentativa bem-sucedida, falha no cache, chamada de API obsoleta)
• ERRO – falhas que afetaram a experiência do usuário (falha na solicitação, pagamento recusado, serviço externo indisponível)
• FATAL – o aplicativo não pode continuar (banco de dados inacessível, configuração necessária ausente)

Retenção de logs e gerenciamento de custos

Os logs são os dados de observabilidade mais caros para armazenar. Implemente a retenção em camadas:

• Armazenamento dinâmico (30 dias) - texto completo pesquisável, consultas rápidas, alto custo
• Armazenamento quente (90 dias) -- consultas compactadas e mais lentas, custo moderado
• Armazenamento frio (mais de 1 ano) -- arquivado, consulta sob demanda, baixo custo
• Logs de depuração - não armazene em produção, a menos que esteja solucionando problemas ativamente

---

Design de Alerta

Alertas incorretos criam fadiga de alertas – as equipes param de responder aos alertas porque a maioria são falsos positivos ou ruídos de baixa prioridade. Um bom alerta revela problemas genuínos que requerem intervenção humana.

Alerta sobre sintomas, não sobre causas

Alerta baseado em sintomas (bom): "A taxa de erros em /api/orders excedeu 1% por 5 minutos" - isso indica diretamente o impacto no usuário, independentemente da causa subjacente.

Alerta baseado em causa (ruim): "CPU do banco de dados excedeu 90%" - isso pode ou não afetar os usuários. O banco de dados pode lidar perfeitamente com 95% da CPU ou pode estar com 50% da CPU, mas completamente bloqueado.

As métricas baseadas em causas pertencem a painéis para investigação, não a regras de alerta.

Níveis de gravidade do alerta

Reduzindo o ruído de alerta

1. Alertas relacionados ao grupo - se o banco de dados ficar inativo, você receberá um alerta de "banco de dados indisponível", e não 50 alertas de cada serviço que depende dele
2. Exigir violação sustentada -- "CPU acima de 90% por 5 minutos" e não "CPU acima de 90% por 1 segundo" para evitar picos transitórios
3. Resolução automática – os alertas devem ser apagados automaticamente quando a condição for resolvida
4. Revisão semanal de alertas – revise todos os alertas disparados, identifique e corrija ou silencie aqueles que não exigiram ação humana
5. Ciclo de feedback de plantão – após cada rotação de plantão, o engenheiro documenta quais alertas foram acionáveis e quais precisam de ajuste

---

SLOs: objetivos de nível de serviço

Os SLOs transformam o monitoramento de reativo ("algo quebrou, conserte") em proativo ("estamos consumindo nosso orçamento de erros, vamos investigar antes que os usuários percebam").

Definindo SLOs

Um SLO define a confiabilidade desejada para um serviço. Consiste em:

• SLI (Indicador de Nível de Serviço) – a métrica que está sendo medida (taxa de sucesso da solicitação, percentil de latência)
• Meta – o limite que define o desempenho aceitável (taxa de sucesso de 99,9%, P95 abaixo de 200 ms)
• Janela: o período durante o qual a meta é avaliada (30 dias consecutivos)

Exemplo de SLOs para uma plataforma de comércio eletrônico

Erro nos orçamentos

O orçamento de erro é o inverso da meta de SLO. Um SLO de 99,9% permite erros de 0,1% – aproximadamente 43 minutos de inatividade por mês. Quando o orçamento de erros se esgota, a equipe muda o foco dos recursos para o trabalho de confiabilidade.

Os orçamentos errados fornecem uma linguagem compartilhada entre as equipes de engenharia e de produto. Em vez de debater se um serviço é “suficientemente confiável”, ambas as equipes podem ver exatamente quanto orçamento de erros resta e tomar decisões baseadas em dados sobre o envio de novos recursos em vez de investir em estabilidade.

---

Perguntas frequentes

Quanto custa a observabilidade em escala?

Os custos de observabilidade variam de US$ 10-50 por host por mês para pilhas de código aberto (Prometheus, Grafana, Loki) a US$ 30-100+ por host para soluções comerciais (Datadog, New Relic). O maior fator de custo é o volume de logs: otimize amostrando logs de depuração, compactando logs armazenados e definindo períodos de retenção apropriados. Para a maioria das empresas com menos de 50 servidores, o custo é de US$ 500 a 2.000 por mês.

Devo usar OpenTelemetry ou agentes específicos do fornecedor?

Utilize o OpenTelemetry. É o padrão do setor para instrumentação, apoiado por todos os principais fornecedores de observabilidade, e evita a dependência de fornecedores. Você pode alternar back-ends (de Datadog para Grafana, por exemplo) sem re-instrumentar seu código. Às vezes, agentes específicos de fornecedores oferecem uma integração mais profunda, mas a compensação pela portabilidade não vale a pena.

Como configuro o monitoramento para um aplicativo NestJS?

No NestJS, use interceptores para temporização de solicitações, filtros de exceção para rastreamento de erros e middleware para propagação de ID de correlação. Integre Sentry com @sentry/nestjs para rastreamento de erros. Exporte métricas do Prometheus com a biblioteca prom-client exposta em um endpoint /metrics. Use o log estruturado com nestjs-pino ou winston configurado para saída JSON.

Qual é a diferença entre monitoramento e observabilidade?

O monitoramento informa quando algo predefinido dá errado (CPU alta, taxa de erro alta, disco cheio). A observabilidade permite fazer novas perguntas sobre o comportamento do sistema sem implantar nova instrumentação. Um sistema é observável quando você pode compreender seu estado interno a partir de suas saídas externas (métricas, logs, rastreamentos). Na prática, um bom monitoramento é um subconjunto da observabilidade.

Como convencer minha equipe a investir em observabilidade?

Acompanhe o tempo médio de resolução (MTTR) para incidentes de produção antes e depois das melhorias de observabilidade. Equipes com boa observabilidade normalmente reduzem o MTTR em 60-70%. Multiplique o tempo economizado pelo custo de engenharia para mostrar o ROI. Acompanhe também o número de incidentes detectados por monitoramento versus relatórios de usuários – a detecção proativa aumenta a confiança do cliente.

---

O que vem a seguir

Comece com o rastreamento de erros (Sentry) se você não tiver nada – ele fornece o valor mais imediato ao detectar e alertar sobre erros de produção. Em seguida, adicione a geração de registros estruturados com IDs de correlação. Em seguida, implemente a coleta de métricas com painéis Prometheus e Grafana. Por fim, adicione rastreamento distribuído quando você tiver vários serviços.

Para obter o contexto completo da engenharia de desempenho, consulte nosso guia de pilares sobre escalando sua plataforma de negócios. Para otimizar a infraestrutura que seu monitoramento monitora, leia nosso guia de escalonamento de infraestrutura.

ECOSIRE implementa pilhas de observabilidade para plataformas de negócios executadas em Odoo ERP e arquiteturas personalizadas. Entre em contato com nossa equipe de DevOps para uma avaliação de monitoramento e observabilidade.

---

Publicado por ECOSIRE — ajudando empresas a escalar com soluções baseadas em IA em Odoo ERP, Shopify eCommerce e OpenClaw AI.