Logs em produção: boas práticas para encontrar erros rápido sem vazar dados

Atualizado em 3 de novembro de 2026 · Leitura de 5 min

Edson Feitosa de Oliveira Junior Fundador e Engenheiro Líder · PruPru Digital Services

Logs em produção são a primeira e, muitas vezes, a única fonte de informação quando algo dá errado. Uma aplicação com bons logs permite descobrir a causa de um erro em minutos. Uma aplicação com logs ruins obriga a tentar reproduzir o problema às cegas, ou a adivinhar. E logs mal feitos ainda podem criar um problema novo: vazar senhas e dados pessoais.

Níveis de log: use cada um para o que serve

Em produção, o nível padrão costuma ser INFO. DEBUG pode ser ativado temporariamente para investigar um problema específico.

Erros comuns: registrar tudo como ERROR (o alerta perde o sentido) ou registrar exceções esperadas, como um usuário digitando uma senha errada, como erro do sistema.

Mensagens que ajudam

Compare:

• Ruim: Erro ao processar
• Bom: Falha ao confirmar pagamento do pedido 8231: gateway respondeu 503 após 3 tentativas

Uma boa mensagem de log diz o que aconteceu, com o quê (identificadores) e por quê, quando se sabe. Ao registrar exceções, inclua a exceção completa, com a stack trace, no nível ERROR. Para interpretar stack traces, veja como ler uma stack trace Java.

Em Java, com SLF4J:

log.error("Falha ao confirmar pagamento do pedido {}", pedidoId, excecao);

Use os parâmetros ({}) em vez de concatenar strings: além de mais eficiente, separa a mensagem dos dados.

Logs estruturados

Em vez de texto livre, registre os logs em JSON, com campos fixos:

{"timestamp":"2026-11-02T14:03:22Z","level":"ERROR","service":"pedidos",
 "requestId":"a1b2c3","pedidoId":8231,"message":"Falha ao confirmar pagamento",
 "error":"GatewayTimeoutException"}

Logs estruturados podem ser filtrados e agregados: "todos os erros do serviço de pedidos na última hora", "tudo o que aconteceu na requisição a1b2c3". O Spring Boot tem suporte a logs estruturados em versões recentes, e bibliotecas como o Logback com encoders JSON fazem isso em versões anteriores. Em Node.js, bibliotecas como pino geram JSON por padrão. Veja JSON para iniciantes.

Identificador de requisição (correlation ID)

Uma única ação do usuário pode gerar dezenas de linhas de log, misturadas com as de outros usuários. Gere um identificador único no início de cada requisição, inclua em todas as linhas de log daquela requisição e devolva no cabeçalho da resposta. Quando um usuário reportar um erro, esse identificador leva direto às linhas certas. Em Java, o MDC (Mapped Diagnostic Context) do SLF4J faz isso de forma transparente.

Em sistemas com vários serviços, propague o identificador entre as chamadas. Padrões como o OpenTelemetry fazem isso automaticamente.

O que nunca registrar nos logs em produção

• Senhas, mesmo erradas.
• Tokens e chaves: cabeçalhos Authorization, cookies de sessão, chaves de API. Veja JWT explicado e variáveis de ambiente e segredos.
• Dados de cartão.
• Dados pessoais desnecessários: CPF completo, endereço, dados de saúde. Quando precisar identificar algo, use identificadores internos ou mascare (*.*.123-45).

Logs costumam ser acessados por mais pessoas e guardados por mais tempo do que o banco de dados, e um vazamento de logs é um vazamento de dados para efeitos da LGPD. Veja LGPD para pequenas empresas.

Cuidado especial com logs automáticos de requisições e respostas HTTP completas e com toString() de objetos que contêm campos sensíveis.

Onde guardar os logs

• Aplicações pequenas: os logs da própria plataforma de hospedagem ou de um servidor com rotação de arquivos configurada (para o disco não encher).
• Aplicações em containers: escreva os logs na saída padrão (stdout) e deixe a plataforma coletar.
• Aplicações maiores ou com vários serviços: centralize em uma ferramenta de agregação de logs, que permite buscar, criar painéis e alertas.

Defina um prazo de retenção: logs não precisam ser guardados para sempre, e guardar menos reduz custo e risco.

Alertas: logs que avisam

Logs que ninguém lê não evitam problemas. Configure alertas para:

• aumento repentino de erros (ERROR);
• respostas 5xx acima de um limite. Veja códigos de status HTTP;
• eventos críticos de negócio, como falhas de pagamento.

Comece com poucos alertas relevantes. Alertas demais viram ruído e são ignorados.

Checklist

• Níveis usados corretamente; INFO como padrão em produção.
• Mensagens com contexto e identificadores.
• Exceções registradas com stack trace.
• Logs estruturados em JSON, com identificador de requisição.
• Nenhuma senha, token ou dado pessoal desnecessário.
• Rotação, retenção definida e alertas para erros.

Logs bem feitos também ajudam na manutenção preventiva de servidores, mostrando problemas antes que eles virem incidentes.

Na prática da PruPru

Num sistema interno que a PruPru construiu para uma distribuidora de Natal, as telas de relatório estavam lentas mesmo com cache configurado. O que revelou a causa foi justamente o log: com o nível TRACE ligado só para o pacote de cache do Spring, ficou claro que as chamadas internas não geravam nenhuma linha de cache, ou seja, o cache nunca era usado. Ligar o nível detalhado de um único pacote, por pouco tempo, resolveu em minutos o que dias de suposição não resolveram. O caso completo está em @Cacheable não funciona no Spring Boot.

Perguntas frequentes