¿Por qué existe el nivel TRACE y cuándo debo usarlo en lugar de DEBUG?

En Log4J, Slf4J y un par de marcos de registro en Java, tiene dos niveles de "desarrollador" para el registro:

• DEPURAR
• RASTRO

Entiendo lo que hace DEBUG, porque la explicación es clara:

El nivel DEBUG designa eventos informativos específicos que son más útiles para depurar una aplicación.

Pero el nivel TRACE no es muy específico sobre su caso de uso:

El Nivel TRACE designa eventos informativos más finos que el DEPURACIÓN

(Fuente: the log4J JavaDoc )

Esto no me dice cómo o cuándo usar TRACE. Curiosamente, este no es un nivel de gravedad definido en el estándar syslog . Buscar en Google la diferencia entre TRACE y DEBUG solo parece devolver "use DEBUG, oh, y también hay TRACE". No pude encontrar un caso de uso específico para el nivel TRACE. Lo mejor que pude encontrar fue esta antigua página wiki debatiendo el mérito de la existencia del nivel.

Esto, como arquitecto, levanta muchas banderas y preguntas en mi cabeza. Si un desarrollador joven me pidiera agregar TRACE a mi arquitectura, lo bombardearía con preguntas:

• ¿Cuáles son algunos ejemplos de información que deberían registrarse con TRACE y no con DEBUG?
• ¿Qué problema específico resuelvo registrando esa información?
• En esos ejemplos, ¿cuáles son las propiedades de la información registrada que discriminan claramente entre el registro en el nivel TRACE en lugar del nivel DEBUG?
• ¿Por qué esa información debe pasar por la infraestructura de registro?
  • ¿Cuáles son los beneficios de mantener esa información en un diario de registros en lugar de solo usarla System.out.println?
  • ¿Por qué es mejor usar log para esto en lugar de un depurador?
• ¿Cuál sería un ejemplo canónico de inicio de sesión en el nivel TRACE?
  • ¿Cuáles son las ganancias específicas que se han logrado al iniciar sesión en el nivel TRACE en lugar de DEBUG en el ejemplo?
  • ¿Por qué son importantes esas ganancias?
  • A la inversa: ¿qué problemas evité al iniciar sesión en TRACE en lugar de DEBUG?
  • ¿De qué otra forma podría resolver esos problemas? ¿Por qué es mejor iniciar sesión en el nivel TRACE que esas otras soluciones?
• ¿Debería dejarse la declaración de registro de nivel TRACE en el código de producción? ¿Por qué?

Pero dado que está presente en la mayoría de los marcos principales, ¿supongo que es útil para algo? Entonces ... ¿para qué sirve TRACE y qué lo distingue de DEBUG?

¿Cuáles son ejemplos de información que debe registrarse con TRACE y no con DEBUG?

Si tengo un algoritmo que sigue varios pasos, el nivel de rastreo imprimirá información sobre cada uno de esos pasos en el nivel más fino. Cosas como las entradas y salidas literales de cada paso.

En general, el rastreo incluirá toda la depuración (al igual que la depuración incluye todas las advertencias y errores).

¿Qué problema específico resuelvo registrando esa información?

Es necesario depurar algo que da salida a manera demasiados datos para iniciar la sesión fuera de una estructura específica cuando se está apuntando esa cosa en particular y no se preocupan por errores u otra información de registro (ya que el volumen de información traza oscurecer ellos). En algunos registradores, activará un determinado módulo hasta el nivel de rastreo solamente.

En esos ejemplos, ¿cuáles son las propiedades de la información registrada que discriminan claramente entre el registro en el nivel TRACE en lugar del nivel DEBUG?

En general, el registro de nivel de rastreo no puede activarse durante períodos prolongados porque degrada el rendimiento de la aplicación en gran medida y / o crea una gran cantidad de datos de registro que no son sostenibles debido a restricciones de disco / ancho de banda.

El registro de nivel de depuración generalmente puede estar activado por un período más largo sin hacer que la aplicación sea inutilizable.

¿Por qué esa información debe pasar por la infraestructura de registro?

No tiene que hacerlo Algunos marcos tienen un rastreador separado.

Por lo general, termina en los registros, ya que los registradores de rastreo y los registradores normales tienen necesidades similares con respecto a la escritura en disco / red, manejo de errores, rotación de registros, etc.

¿Por qué es mejor usar log para esto en lugar de un depurador?

Debido a que el depurador podría no poder conectarse a la máquina con problemas. Es posible que no sepa lo suficiente como para saber dónde establecer puntos de interrupción o para pasar por el código. Es posible que no pueda reproducir de manera confiable el error en un depurador, por lo tanto, use los registros para detectarlo "si sucede".

Pero son solo nombres. Como cualquier otra etiqueta, son solo nombres que las personas ponen en las cosas, y generalmente significarán cosas diferentes para diferentes personas. Y la etiqueta en sí es menos importante que los trozos carnosos a los que se refiere la etiqueta.

Tenga en cuenta que slf4j recomienda específicamente no usar el rastreo ( http://slf4j.org/faq.html#trace ):

En resumen, aunque todavía desalentamos el uso del nivel TRACE porque existen alternativas o porque en muchos casos las solicitudes de registro del nivel TRACE son un desperdicio, dado que la gente seguía pidiéndolo, decidimos someternos a la demanda popular.

Personalmente, mi expectativa sería que trace rastreara todo (por ejemplo, incluso cosas como "ingresó la función MyFunc con argumentos A, B, C en el momento Y"). La desventaja de esto es que no solo es increíblemente ruidoso, sino que también tiende a causar problemas de espacio en disco; Esperaría que tal registro se deshabilite durante las operaciones normales. Lo bueno es que esto le brinda un nivel de información similar al que obtendría al recorrer su programa en casos en los que adjuntar un depurador puede ser menos práctico.

En general, encuentro que el rastreo suele ser más esfuerzo que otros enfoques.

Los niveles de depuración en general son completamente arbitrarios y pueden variar entre idiomas, bibliotecas y empresas.

Dicho esto, así es como los he visto utilizados:

TRACE: se usa para mostrar el flujo del programa a nivel lógico. Entró en una función? ¿Una declaración "if" eligió la rama principal o "else"? Ese es un candidato para la traza. En otras palabras, el registro de rastreo se usa generalmente para especificar "estás aquí". Esto es útil en el contexto de otra declaración de registro que podría registrar un error u otra información. El registro de rastreo puede ayudar a identificar la ubicación, en el código, del error u otro evento registrado en un nivel diferente.

DEPURACIÓN: se utiliza para volcar estado variable, códigos de error específicos, etc. Por ejemplo: un servicio web podría devolver el código de error 809214, que podría registrarse mientras la aplicación le dice al usuario "falla de comunicación". Imagine que un desarrollador recibe un registro del sistema de un usuario mucho después de que ocurrió el error y se pregunta " ¿por qué ocurrió la falla?" Eso es bueno para iniciar sesión en el nivel de depuración. Otro ejemplo podría ser si se produce un error en la producción pero es difícil de reproducir, depurar el registro de ciertas variables o eventos en el módulo problemático para ayudar a informar a los desarrolladores el estado del programa cuando se produce el error para ayudar a solucionar problemas.

Normalmente uno configuraría la aplicación para iniciar sesión en un nivel dado (o superior). Por ejemplo, el rastreo suele ser el nivel más bajo: el registro en ese nivel registra todo. El nivel de depuración omitiría el rastreo pero incluiría niveles altos (por ejemplo, advertencias y errores).

El beneficio de segregar los niveles de registro es controlar la cantidad registrada. Para una aplicación compleja, el registro de rastreo podría registrar una gran cantidad de datos, la mayoría de los cuales son inútiles la mayor parte del tiempo. Es mejor solo registrar información crítica (tal vez algo de información de inicio, luego solo errores) a menos que uno esté tratando de determinar cómo causar un error. Además, esto generalmente solo es útil en un entorno de producción donde los depuradores y otras herramientas de desarrollo no están presentes.

No hay límites reales para esto, no hay reglas que indiquen que debe iniciar sesión de cierta manera. Solo convenciones amplias que algunas bibliotecas o aplicaciones pueden seguir o no.

Creo que la excelente respuesta de Telastyn se puede resumir en mi breve regla general:

• DEBUG el registro debe poder utilizarse en la producción (pero tiende a estar apagado normalmente)
• TRACE se permite que el registro sea tal que no sea factible usarlo en producción (que no sea para una sesión específica / corta)

Aquí está mi regla de oro

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)

La suposición detrás de esto es que el equipo de operaciones

• siempre tenga la producción configurada en información de nivel de registro
• podría tener la producción establecida en depuración a nivel de registro
• nunca tenga la producción configurada en el rastreo de nivel de registro

Armado con esa suposición, así es como usted, como desarrollador, puede usar los niveles de registro ...

Problema # 1) no ralentizar demasiado el rendimiento de producción

debugresuelve # 1. Es usted, como desarrollador, haciendo todo lo posible para equilibrar la información que pueda necesitar en la producción sin tener demasiado ruido, ralentizando la máquina. Está diciendo "es una buena idea registrar esto constantemente en producción (si lo desea)".

Problema # 2) tener información detallada mientras se desarrolla

traceresuelve el problema # 2. No le preocupa en absoluto el impacto que tendría en una máquina de producción, pero necesita esa información ahora mismo mientras desarrolla el código. Usted dice "No prometo que sea una buena idea registrar siempre esta información en producción".

Por supuesto (como han dicho otros), estas cosas son arbitrarias; así que solo asegúrese de que su equipo de desarrollo (y el equipo de operaciones / monitoreo, porque también son usuarios de su registro) estén de acuerdo en algo.

¿Cuál sería un ejemplo canónico de inicio de sesión en el nivel TRACE?

ENTRAR / SALIR registra desde un método. Estos registros lo ayudan a rastrear el flujo del programa y tienden a ser muy útiles cuando:

1. El programa se bloquea abruptamente: usted sabe exactamente en qué función se bloqueó al mirar la última línea del registro

2. Algunas funciones no autorizadas fallan silenciosamente al absorber una excepción

Garantizan un nivel de RASTREO separado en lugar de solo usar DEBUG porque habilitar los registros de ENTRADA / SALIDA para cada método en su base de código generará una enorme cantidad de registros adicionales que no son razonables para estar siempre activados , incluso en un contexto de DEPURACIÓN.