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

  

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

Si tengo un algoritmo que pasa por varios pasos, el nivel de seguimiento 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 seguimiento incluirá toda la depuración (al igual que la depuración incluye todas las advertencias y errores).

  

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

Necesita depurar algo que genere demasiados datos para way para iniciar sesión fuera de una compilación específica cuando se dirige a esa cosa en particular y no le importan los errores o otra información de registro (ya que el volumen de información de rastreo los ocultará). En algunos registradores, cambiará un determinado módulo solo al nivel de seguimiento.

  

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

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

Por lo general, el registro de nivel de depuración puede estar activo durante un período más largo sin inutilizar la aplicación.

  

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

No tiene que hacerlo. Algunos marcos tienen un tracelogger separado.

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

  

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

Debido a que el depurador podría no ser capaz de conectarse a la máquina problemática. Es posible que no sepa lo suficiente como para saber dónde establecer puntos de interrupción o cómo pasar por el código. Es posible que no pueda reproducir de forma confiable el error en un depurador, así que use los registros para detectarlos "si sucede".

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

Tome nota especial de que slf4j recomienda específicamente no usar trace ( enlace ):

  

En resumen, aunque todavía desalentamos el uso del nivel TRACE   Porque existen alternativas o porque en muchos casos las solicitudes de registro de   El nivel TRACE es un desperdicio, dado que las personas lo pedían, nosotros   decidió inclinarse ante la demanda popular.

Personalmente, mi expectativa sería que el rastreo registre todo (por ejemplo, incluso cosas como "la función ingresada MyFunc con los argumentos A, B, C en el momento Y"). La desventaja de esto es que no solo es increíblemente ruidoso sino que también causa problemas de espacio en el disco; Espero que dicho registro se deshabilite durante las operaciones normales. La ventaja es que esto le proporciona un nivel de información similar al que obtendría al avanzar en su programa en los casos en que adjuntar un depurador puede ser menos práctico.

En general, me parece que el seguimiento suele ser más un 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 usar:

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 main o "else"? Ese es un candidato para rastrear. En otras palabras, el registro de seguimiento se usa generalmente para especificar "usted está 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 seguimiento puede ayudar a identificar la ubicación, en el código, del error u otro evento registrado en un nivel diferente.

DEBUG: se utiliza para descargar el estado variable, códigos de error específicos, etc. Por ejemplo: un servicio web puede devolver el código de error 809214, que podría registrarse mientras la aplicación le dice al usuario "comunicación fallida". Imagine a un desarrollador que recibe un registro del sistema de un usuario mucho después de que se produjo el error y se pregunta " ¿por qué se produjo el error?" eso es una buena cosa para iniciar sesión en el nivel de depuración. Otro ejemplo podría ser si un error sigue ocurriendo en la producción pero es difícil de reproducir, depure el registro de ciertas variables o eventos en el módulo problemático para ayudar a los desarrolladores a informar sobre el estado del programa cuando ocurre 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 es a menudo el nivel más bajo: el registro en ese nivel registra todo. El nivel de depuración omitiría la traza 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 seguimiento podría potencialmente registrar una tremenda cantidad de datos, la mayoría de ellos inútiles la mayor parte del tiempo. Solo es mejor registrar información crítica (tal vez 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 tienes que iniciar sesión de cierta manera. Solo las convenciones generales que algunas bibliotecas o aplicaciones pueden o no seguir.

Creo que La excelente respuesta de Telastyn se puede resumir en mi breve regla de oro:

• El registro DEBUG debe poder usarse en producción (pero tiende a estar apagado normalmente)
• Se permite que TRACE logging sea tal que su uso en producción (que no sea para una sesión específica / corta) sea inviable

Aquí '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 lo hará

• siempre tiene el conjunto de producción a información de nivel de registro
• puede tener un conjunto de producción para la depuración a nivel de registro
• nunca tiene el conjunto de producción para el rastreo a nivel de registro

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

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

debug resuelve # 1. Es usted, como desarrollador, quien hace todo lo posible para equilibrar la información que puede necesitar en la producción con no tener demasiado ruido, lo que hace que la máquina sea más lenta. Está diciendo que "es una buena idea registrar constantemente esto en producción (si lo desea)".

Problema # 2) tener información detallada al desarrollar

trace resuelve el problema # 2. No tiene absolutamente ninguna preocupación sobre 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 está diciendo "No prometo que es una buena idea registrar siempre esta información en producción".

Por supuesto (como han dicho otros), estas cosas son arbitrarias; así que 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 registro en el nivel TRACE?

Los registros ENTRY / EXIT de un método. Estos registros le 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ó mirando la última línea del registro

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

Garantizan un nivel TRACE separado en lugar de simplemente usar DEBUG porque habilitar los registros ENTRY / EXIT para cada método en su base de código generará una cantidad tremenda de registros adicionales que no son razonables para que siempre esté en , incluso en un contexto DEBUG.

Use TRACE cuando necesite detalles más finos de los que DEBUG puede proporcionar, más probablemente cuando esté solucionando un problema particularmente difícil.

Si se trata de su propio código, debe escribirlo de tal manera que nunca necesite ninguno de estos niveles de registro. Una forma de hacerlo es practicar TDD. Escribir su código en unidades pequeñas que están bien cubiertas por pruebas de unidad reduce en gran medida la necesidad de registro y depuración, excepto el registro que se produce como parte de la función normal de la aplicación. Es muy poco probable que ese tipo de registro ocurra a nivel TRACE o DEBUG.

Utilice siempre el nivel de registro que proporciona el nivel de detalle más pequeño que sea suficiente. Esto reduce tanto como sea posible la cantidad de datos de registro que debe analizar. Dicho esto, no hay reglas estrictas y rápidas para qué nivel de registro usar en un escenario determinado. Usa el que te sea más útil.