Por que o nível TRACE existe e quando devo usá-lo em vez de DEBUG?

No Log4J, Slf4J e algumas outras estruturas de log em Java, você tem dois níveis de "desenvolvedor" para o log:

• DEPURAR
• VESTÍGIO

Eu entendo o que DEBUG faz, porque a explicação é clara:

O nível DEBUG designa eventos informativos refinados que são mais úteis para depurar um aplicativo.

Mas o nível TRACE não é muito específico sobre seu caso de uso:

O nível TRACE designa eventos informativos mais refinados que o DEBUG

(Fonte: o log4J JavaDoc )

Isso não me diz como ou quando usar o TRACE. Curiosamente, este não é um nível de gravidade definido no padrão syslog . Pesquisando a diferença entre TRACE e DEBUG apenas parece retornar "use DEBUG, oh, e existe TRACE também". Não foi possível encontrar um caso de uso específico para o nível TRACE. O melhor que pude encontrar foi esta antiga página wiki debatendo o mérito da existência do nível.

Isso, como arquiteto, gera muitas bandeiras e perguntas na minha cabeça. Se um jovem desenvolvedor me pedisse para adicionar o TRACE à minha arquitetura, eu o bombardearia com perguntas:

• Quais são alguns exemplos de informações que devem ser registradas no TRACE e não no DEBUG?
• Que problema específico eu resolvo registrando essas informações?
• Nesses exemplos, quais são as propriedades das informações registradas que discriminam claramente entre o registro no nível TRACE e não no nível DEBUG?
• Por que essas informações devem passar pela infraestrutura de log?
  • Quais são os benefícios de manter essas informações em um diário de logs em vez de apenas usá-las System.out.println?
  • Por que é melhor usar o log para isso do que um depurador?
• O que seria um exemplo canônico de registro no nível TRACE?
  • Quais são os ganhos específicos que foram obtidos registrando-se no nível TRACE em vez de DEBUG no exemplo?
  • Por que esses ganhos são importantes?
  • Por outro lado: que problemas eu evitei registrando-o no TRACE em vez de DEBUG?
  • De que outra forma eu poderia resolver esses problemas? Por que o log no nível TRACE é melhor do que as outras soluções?
• A instrução de log no nível TRACE deve ser deixada no código de produção? Por quê?

Mas, como está presente na maioria dos quadros principais, acho que é útil para alguma coisa? Então ... para que serve o TRACE e o que o distingue do DEBUG?

Quais são os exemplos de informações que devem ser registradas no TRACE e não no DEBUG?

Se eu tiver um algoritmo que execute várias etapas, o nível de rastreamento imprimirá informações sobre cada uma dessas etapas no nível mais fino. Coisas como as entradas e saídas literais de cada etapa.

Em geral, o rastreamento inclui todas as depurações (assim como a depuração inclui todos os avisos e erros).

Que problema específico eu resolvo registrando essas informações?

Você precisa depurar algo que gera maneira demasiados dados para log fora de uma compilação específica quando você está alvejando essa coisa particular e não se preocupam com erros ou outras informações de log (uma vez que o volume de informações de rastreio irá obscurecer-los). Em alguns registradores, você transformará um determinado módulo apenas no nível de rastreamento.

Nesses exemplos, quais são as propriedades das informações registradas que discriminam claramente entre o registro no nível TRACE e não no nível DEBUG?

Em geral, o log no nível de rastreio não pode ser ativado por períodos prolongados porque prejudica bastante o desempenho do aplicativo e / ou cria uma abundância de dados de log que são insustentáveis ​​devido a restrições de largura de banda / disco.

Geralmente, o log no nível de depuração pode ficar ativo por um longo período sem tornar o aplicativo inutilizável.

Por que essas informações devem passar pela infraestrutura de log?

Não precisa. Algumas estruturas têm um tracelogger separado.

Geralmente, ele acaba nos logs, pois os registradores tracelog e normais têm necessidades semelhantes em relação à gravação em disco / rede, tratamento de erros, rotação de logs etc.

Por que é melhor usar o log para isso do que um depurador?

Porque o depurador pode não conseguir se conectar à máquina com problema. Talvez você não saiba o suficiente para saber onde definir pontos de interrupção ou percorrer o código. Talvez você não consiga reproduzir o erro de maneira confiável em um depurador, portanto, use os logs para capturá-lo "se acontecer".

Mas são apenas nomes. Como qualquer outra gravadora, são apenas nomes que as pessoas colocam e geralmente significam coisas diferentes para pessoas diferentes. E o próprio rótulo é menos importante do que os pedaços de carne aos quais o rótulo se refere.

Observe que o slf4j recomenda especificamente o uso de trace ( http://slf4j.org/faq.html#trace ):

Em resumo, embora ainda desencorajemos o uso do nível TRACE porque existem alternativas ou porque, em muitos casos, as solicitações de log do nível TRACE são um desperdício, uma vez que as pessoas continuavam solicitando, decidimos nos curvar à demanda popular.

Pessoalmente, minha expectativa seria que o rastreamento registrasse tudo (por exemplo, até coisas como "função MyFunc inserida com os argumentos A, B, C no momento Y"). A desvantagem disso é que não só isso é incrivelmente barulhento, mas também tende a causar problemas de espaço em disco; Eu esperaria que esse log fosse desativado durante operações normais. A vantagem é que isso fornece um nível de informação semelhante ao que você obteria ao percorrer seu programa nos casos em que anexar um depurador pode ser menos prático.

Geralmente, acho que o rastreamento costuma ser mais trabalhoso do que outras abordagens.

Os níveis de depuração em geral são totalmente arbitrários e podem variar entre idiomas, bibliotecas e empresas.

Dito isto, eis como os vi usados:

TRACE: usado para mostrar o fluxo do programa no nível lógico. Entrou em uma função? Uma declaração "if" escolheu o ramo principal ou "else"? Esse é um candidato para rastreamento. Em outras palavras, o log de rastreamento geralmente é usado para especificar "você está aqui". Isso é útil no contexto de outra instrução de log que pode registrar um erro ou outras informações. O log de rastreamento pode ajudar a identificar o local, no código, do erro ou outro evento registrado em um nível diferente.

DEBUG: usado para despejar estado variável, códigos de erro específicos etc. Por exemplo: um serviço da web pode retornar o código de erro 809214, que pode ser registrado enquanto o aplicativo informa ao usuário "falha na comunicação". Imagine um desenvolvedor recebendo um log do sistema de um usuário muito tempo após o erro e se perguntando " por que a falha ocorreu?" isso é uma coisa boa para fazer logon no nível de depuração. Outro exemplo pode ser se um bug continuar ocorrendo na produção, mas for difícil de reproduzir, o log de depuração de determinadas variáveis ​​ou eventos no módulo problemático para ajudar a informar aos desenvolvedores o estado do programa quando o erro ocorrer para ajudar na solução de problemas.

Normalmente, você configuraria o aplicativo para registrar em um determinado nível (ou superior). Por exemplo, o rastreamento geralmente é o nível mais baixo: o log nesse nível registra tudo. O nível de depuração omitiria o rastreamento, mas incluiria níveis altos (por exemplo, avisos e erros).

O benefício de segregar os níveis de log é controlar o valor registrado. Para um aplicativo complexo, o log de rastreamento pode registrar uma quantidade enorme de dados, muitos deles inúteis na maioria das vezes. É melhor apenas registrar informações críticas (talvez algumas informações de inicialização, depois apenas erros), a menos que alguém esteja tentando descobrir como causar um bug. Além disso, isso geralmente é útil apenas em um ambiente de produção, onde depuradores e outras ferramentas de desenvolvimento não estão presentes.

Não há limites reais para isso, nem regras dizendo que você precisa registrar de uma certa maneira. Somente convenções amplas que algumas bibliotecas ou aplicativos podem ou não seguir.

Penso que a excelente resposta de Telastyn pode ser resumida na minha curta regra de ouro:

• DEBUG o registro deve ser capaz de ser usado na produção (mas tende a permanecer normalmente desativado)
• TRACE é permitido que o registro seja tal que o uso na produção (exceto para uma sessão específica / curta) seja inviável

Aqui está minha regra de ouro

error   you need        to do something
warn    you might need  to do something
info    you need        to log this in production
debug   you might need  to log this in production
trace   everything that is happening (no performance concerns)

A suposição por trás disso é que a equipe de operações irá

• sempre tenha a produção configurada para informações no nível do log
• pode ter a produção configurada para depuração no nível do log
• nunca tenha a produção configurada para rastreamento no nível do log

Armado com essa suposição, veja como você, como desenvolvedor, pode usar os níveis de log ...

Problema nº 1) não diminuindo muito o desempenho da produção

debugresolve # 1. É você, como desenvolvedor, fazendo o possível para equilibrar as informações necessárias na produção, pois, se não houver muito barulho, diminui a velocidade da máquina. Você está dizendo "é uma boa idéia registrar isso constantemente na produção (se você quiser)".

Problema nº 2) ter informações detalhadas durante o desenvolvimento

traceresolve o problema # 2. Você não tem absolutamente nenhuma preocupação com o impacto que isso teria em uma máquina de produção, mas você precisa dessas informações agora mesmo ao desenvolver o código. Você está dizendo "Não prometo que é uma boa idéia registrar sempre essas informações na produção".

Concedido (como outros já disseram), essas coisas são arbitrárias; portanto, certifique-se de que sua equipe de desenvolvimento (e equipe de operações / monitoramento - porque eles também são usuários do seu log) concordem com alguma coisa.

O que seria um exemplo canônico de registro no nível TRACE?

Registros de entrada / saída de um método. Esses logs ajudam a rastrear o fluxo do programa e tendem a ser muito úteis quando:

1. O programa trava abruptamente - você sabe exatamente em qual função ele travou olhando a última linha do log

2. Alguma função não autorizada falha silenciosamente ao absorver uma exceção

Eles garantem um nível TRACE separado, em vez de apenas usar DEBUG, porque habilitar logs ENTRY / EXIT para todos os métodos em sua base de código gerará uma quantidade enorme de logs extras que não são razoáveis ​​para serem sempre ativados , mesmo em um contexto DEBUG.