Monitoramento: o que acompanhar num sistema em produção

Monitorar um sistema em produção se resume a cinco sinais: está no ar, está errando, está lento, está saturado e quanto está custando. Quem cobre esses cinco descobre a maioria dos problemas antes do cliente ligar. E o erro mais comum não é monitorar de menos, é criar tantos alertas que a equipe aprende a ignorá-los, o que é pior do que não ter alerta nenhum.

Sinal 1: disponibilidade

A verificação básica: alguém de fora consegue acessar o sistema?

• Monitore de fora do seu servidor. Verificação rodando na mesma máquina não detecta a máquina caindo.
• Verifique um endpoint que exercite o banco, não apenas uma página estática. Aplicação de pé com banco fora ainda responde 200 na home.
• Intervalo de 1 a 5 minutos, com alerta após duas falhas seguidas para evitar ruído de rede.
• Monitore também o certificado TLS. Certificado vencido derruba o sistema tão bem quanto um servidor desligado, e é totalmente evitável, alerte com 20 dias de antecedência.

Sinal 2: taxa de erro

É a métrica que mais se aproxima da experiência real do usuário. Acompanhe:

• Percentual de respostas 5xx sobre o total, por endpoint
• Percentual de 4xx, que revela problema de integração ou de interface
• Exceções não tratadas, agrupadas por tipo
• Falhas em tarefas de segundo plano, filas e agendamentos falham em silêncio com frequência

Um limite razoável para começar: alerte se a taxa de erro passar de 1% em uma janela de 5 minutos. Ajuste com os dados reais depois de algumas semanas.

Uma ferramenta de rastreamento de exceções (Sentry, GlitchTip ou equivalente) vale mais que qualquer painel bonito aqui: ela entrega o erro com o rastro completo e o contexto da requisição, o que corta o tempo de diagnóstico.

Sinal 3: latência

Tempo de resposta, sempre em percentil, nunca em média.

Acompanhe por endpoint, não só o número global. A média geral fica boa porque a maioria das requisições é leve; o problema mora nas três telas que importam.

Referências práticas para sistema de gestão: p95 abaixo de 500 ms é bom, entre 500 ms e 1,5 s é aceitável, acima de 3 s gera reclamação. Relatórios pesados merecem limite próprio e, de preferência, processamento assíncrono.

Sinal 4: saturação

Quanto dos recursos disponíveis está em uso. Serve para prever o problema antes de virar incidente:

• CPU e memória do servidor e de cada container
• Espaço em disco, a causa mais boba e mais frequente de queda. Alerte em 80%.
• Conexões do banco de dados em uso versus o limite do pool
• Tamanho da fila de tarefas pendentes e tempo de espera
• Consultas lentas por minuto, que sobem antes da latência geral

Disco cheio, pool esgotado e fila crescendo são os três que mais derrubam sistema em pequena empresa, e os três dão aviso com antecedência se alguém estiver olhando.

Sinal 5: custo

Monitoramento de custo raramente é configurado e quase sempre faz falta:

• Orçamento com alerta no provedor de nuvem, disparando em 50%, 80% e 100% do previsto
• Gasto por chamada de API externa, gateway, e-mail, mensageria
• Consumo de modelos de IA, se houver, medido por tokens e por funcionalidade

Sistemas com IA merecem atenção especial: um laço mal desenhado ou um agente em recursão consome orçamento de um mês em uma tarde. Limite de gasto configurado no fornecedor é a proteção mais efetiva.

Logs: guardar de forma que dê para procurar

Log espalhado em arquivo dentro do servidor só é útil para quem tem acesso ao servidor e sabe onde procurar. Centralize, e siga três regras:

1. Formato estruturado (JSON), com campos fixos, para permitir busca por usuário, cliente ou requisição
2. Identificador de correlação por requisição, propagado entre serviços, para reconstruir o caminho completo
3. Nada de dado sensível, senha, token, cartão, dado pessoal desnecessário. Log vai parar em ferramenta de terceiro e é lido por muita gente

Retenção de 15 a 30 dias resolve investigação de incidente. Log de auditoria é outra coisa, com retenção própria e muito mais longa.

Alerta que funciona

Regra única: todo alerta que dispara precisa exigir uma ação. Se a resposta certa for "ah, isso acontece direto", ele não deveria existir. Alerta ignorado treina a equipe a ignorar todos, inclusive o que importa.

Um conjunto inicial enxuto e suficiente:

• Sistema fora do ar por mais de 2 minutos
• Taxa de erro acima de 1% por 5 minutos
• p95 acima do limite acordado por 10 minutos
• Disco acima de 85%
• Backup não gerado nas últimas 26 horas
• Fila com mais de X itens pendentes por 15 minutos
• Certificado expirando em menos de 20 dias
• Orçamento de nuvem ou de IA acima do previsto

Defina quem recebe e por qual canal, separando o que acorda alguém de madrugada do que pode esperar o horário comercial. Um alerta noturno que não exigia ação imediata custa mais caro do que parece.

Ferramentas

Para sistema pequeno e médio, uma combinação que funciona: monitoramento externo de uptime em plano gratuito, rastreamento de exceções para erros, e Prometheus com Grafana rodando no próprio servidor para métricas e painéis. É a stack que usamos na Retti Tech para acompanhar os sistemas em produção, e o custo de infraestrutura é marginal.

O que decide o resultado não é a ferramenta, e sim ter os cinco sinais cobertos e uma lista curta de alertas que as pessoas realmente leem.