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

What are example of information that should be logged with TRACE and not with DEBUG?

Se eu tiver um algoritmo que passe por várias etapas, o nível de rastreio exibirá informações sobre cada uma dessas etapas no melhor nível. Coisas como entradas e saídas literais de cada passo.

Em geral, o rastreio incluirá toda a depuração (assim como a depuração inclui todos os avisos e erros).

What specific problem do I solve by logging that information?

Você precisa depurar algo que produza maneira dados em excesso para fazer logoff de uma compilação específica quando estiver segmentando essa coisa específica e não se importar com erros ou outras informações de registro (já que o volume de informações de rastreio irá obscurecê-las). Em alguns registradores, você transformará um determinado módulo em um nível de rastreamento apenas.

In those examples, what are the properties of the logged information that clearly discriminate between logging at the TRACE level rather than the DEBUG level?

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

O registro em nível de depuração geralmente pode ser ativado por um período mais longo sem tornar o aplicativo inutilizável.

Why does that information must go through the log infrastructure?

Não é necessário. Alguns frameworks possuem um tracelogger separado.

Normalmente, ele acaba nos registros, já que os rastreadores e os registradores normais têm necessidades similares em relação à gravação em disco / rede, tratamento de erros, rotação de logs, etc.

Why is it better to use log for this rather than a debugger?

Como o depurador pode não conseguir se conectar à máquina com problema. Você pode não saber o suficiente para saber onde definir os pontos de interrupção ou passar pelo código. Você pode não conseguir reproduzir o erro de forma confiável em um depurador, portanto, use os logs para capturá-lo "se isso acontecer".

Mas eles são apenas nomes. Como qualquer outro rótulo, eles são apenas nomes que as pessoas colocam nas coisas e geralmente significam coisas diferentes para pessoas diferentes. E o rótulo em si é menos importante que os pedaços de carne a que o rótulo se refere.

Observe que o slf4j recomenda especificamente o uso de rastreio ( link ):

In short, although we still discourage the use of the TRACE level because alternatives exist or because in many cases log requests of level TRACE are wasteful, given that people kept asking for it, we decided to bow to popular demand.

Pessoalmente, minha expectativa seria que o rastreio registrasse tudo (por exemplo, até mesmo coisas como "entrou na função MyFunc com os argumentos A, B, C na hora 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 seja desativado durante as operações normais. A vantagem é que isso fornece um nível de informações semelhante ao que você obteria ao percorrer seu programa nos casos em que anexar um depurador pode ser menos prático.

Geralmente, acho que esse rastreio geralmente é mais um esforço 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 utilizados:

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

DEPURAÇÃO: usada para descarregar estado de 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 depois que o erro ocorreu e perguntando " por que a falha ocorreu?" isso é bom registrar no nível de depuração. Outro exemplo pode ser se um bug continua ocorrendo na produção, mas é difícil de reproduzir, depurar log 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, é necessário configurar o aplicativo para registrar em um determinado nível (ou superior). Por exemplo, trace geralmente é o nível mais baixo: o registro 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 registro de rastreio pode potencialmente registrar uma enorme quantidade de dados, em grande parte inúteis na maior parte do tempo. É melhor apenas registrar informações críticas (talvez algumas informações de inicialização, somente erros) alguém esteja tentando descobrir como causar um erro. 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.

Acho que a excelente resposta do Telastyn pode ser resumida na minha curta regra prática:

• DEBUG logging deve poder ser usado na produção (mas tende a estar normalmente desligado)
• TRACE logging é permitido ser tal que usá-lo em produção (diferente de uma sessão específica / curta) é inviável

Aqui, minha regra geral

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 ops irá

• sempre tem produção definida para informações no nível do log
• pode ter produção definida como depuração no nível do log
• nunca tem produção definida como nível de log

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

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

debug resolve # 1. É você, como desenvolvedor, fazendo o seu melhor para equilibrar as informações que você pode precisar em produção, sem ter muito ruído, tornando a máquina mais lenta. Você está dizendo "é uma boa ideia registrar isso constantemente em produção (se quiser)".

Problema # 2) tendo informações detalhadas durante o desenvolvimento

trace resolve o problema # 2. Você não tem absolutamente nenhuma preocupação sobre o impacto que isso teria em uma máquina de produção, mas você precisa dessa informação agora enquanto desenvolve o código. Você está dizendo "Eu não faço promessas de que é uma boa ideia sempre registrar essas informações em produção".

Concedida (como outros disseram), essas coisas são arbitrárias; então apenas certifique-se de que sua equipe de desenvolvimento (e ops / equipe de monitoramento - porque eles também são usuários do seu registro) concordem em algo.

What would be a canonical example of logging at the TRACE level?

ENTRY / EXIT registra de um método. Esses logs ajudam você 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 caiu olhando a última linha do log

2. Algumas funções não autorizadas silenciosamente falham ao absorver uma exceção

Eles garantem um nível TRACE separado, em vez de apenas usar DEBUG, pois a ativação de logs ENTRY / EXIT para cada método em sua base de código gerará uma enorme quantidade de logs extras que não são razoáveis sempre , mesmo em um contexto de DEBUG.

Use o TRACE quando precisar de detalhes mais detalhados do que o DEBUG pode fornecer, provavelmente quando estiver solucionando um problema particularmente difícil.

Se é o seu próprio código, você deve escrevê-lo de tal forma que você nunca precisará de nenhum desses níveis de log. Uma maneira de fazer isso é praticar o TDD. Escrever seu código em unidades pequenas que são bem cobertas por testes de unidade reduz muito a necessidade de registro e depuração, exceto para registro que ocorre como parte da função normal do aplicativo. É muito improvável que esse tipo de registro ocorra no nível TRACE ou DEBUG.

Sempre use o nível de log que forneça o menor nível de detalhes que seja suficiente. Isso reduz o máximo possível a quantidade de dados de log que você precisa filtrar. Dito isso, não há regras rígidas e rápidas para qual nível de registro usar em qualquer cenário. Use o que for mais útil para você.