Formas de estandarizar el registro en una gran aplicación Java

Question

En una aplicación grande el registro es esencial, pero cuando muchos desarrolladores trabajan en el código, los registros pueden volverse caóticos. Se podría escribir:

log.info("Loaded " + rowCount + " recodrs from the database."); 

Otro podría hacer algo como:

log.debug("Records read={}", rowCount); 

Un tercer desarrollador podría pensar que esto es la forma correcta:

log.trace("Record(s) read: " + NumberFormat.getInstance().format(rowCount) 
      + ", values: " + values); 

Esto dará lugar a los registros que son difíciles para leer, y mucho más difícil de analizar.

¿Qué orientación puede darle a los desarrolladores para que produzcan registros que tengan la oportunidad de ser consistentes y de que puedan ser utilizados por otras personas? ¿Será útil una política sobre la explotación forestal? Y si es así, ¿qué debería incluir? ¿Debería haber una API (por encima del marco de trabajo de registro) para hacer cumplir esta política?

También tengo curiosidad acerca de cómo hacer que el código se vea igual, pero la pregunta más importante es acerca de la salida real.

Answer 1

directrices de registro en mi humilde opinión sobre lo que constituye un buen nivel de los estados de registro son poco comunes incluso entre los grandes marcos y productos, debido principalmente directrices más importantes que implican

• Entrar verbosidad - declaraciones más detallados deben aparecer como sentencias de depuración y llamadas a log.debug() debería completarse con una llamada para verificar si la depuración está habilitada. Los desarrolladores a menudo necesitan obtener la distinción correcta entre FATAL, ERROR, INFO, DEBUG y TRACE: no todas las excepciones son fatales, y no todos los mensajes son informativos.
• Uso de TRACE o equivalente - esto debe reservarse para el flujo de ejecución. Idealmente, no se requieren otras instrucciones de registro para indicar el flujo de control.
• DEBUG vs INFO - Las afirmaciones de DEBUG se hacen a menudo para desarrolladores y personal de soporte; INFO es a menudo para usuarios y administradores.
• anulación toString() - es útil para registrar el estado de los objetos complejos

Dicho esto, sigue algunas reglas del pulgar general a nivel más bajo: los datos

• de registro como es, sin formatear. De esa forma, en caso de error, sé cuáles fueron los datos que causaron el problema, en lugar de dudar del registrador, el formateador y la aplicación al mismo tiempo.
• Evita crear demasiados objetos String a menos que estés utilizando DEBUG o TRACE encendidos. En resumen, evite concatenar demasiadas cadenas. Incluso si log4j comprueba eventualmente si DEBUG está habilitado o no, los objetos String han sido creados, y es por eso que el registro de llamadas es importante. slf4j helps avoids this via the use of parameterized messages.

Answer 2

Puede usar AOP (AspectJ es el mejor) para registrar lo que se pasa a los métodos. incluso podría hacer un corte de punto a solo métodos, por lo que no será demasiado registro. Puede escribir una anotación de método como @Loggable y establecer punto de corte en él, de modo que cada método con esos params se registra.

Creo que los aspectos son la mejor manera de hacerlo aquí.

example

Answer 3

normalizar los mensajes, ya sea a través de la API o cadena formatos hacen referencia a los desarrolladores en la construcción de las declaraciones de registro. No deberían escribir un texto así en el programa, ni siquiera para el registro, por las razones exactas por las que llamas. Naturalmente, esto significa que también necesita una política y revisiones para garantizar que se respete la política.