¿Cómo saber si hay demasiados mensajes de registro?

Question

Encontré una muy buena biblioteca para analizar archivos CUE. Pero cuando empecé a leer su código fuente, me di cuenta de que es casi ilegible:

public void setParent(final CueSheet parent) { 
    FileData.logger.entering(FileData.class.getCanonicalName(), "setParent(CueSheet)", parent); 
    this.parent = parent; 
    FileData.logger.exiting(FileData.class.getCanonicalName(), "setParent(CueSheet)"); 
} 

cada método ha logger.entering() y() logger.exiting mensajes. ¿No es eso demasiado?

Hay otra biblioteca de java para analizar las etiquetas de audio. También tenía como 15 mensajes de registro para cada archivo que leía. Fue molesto, así que comenté cada llamada al registrador. Y la biblioteca se convirtió en el doble de rápido, porque usaron una gran cantidad de concatenación de cadenas para los mensajes de registro.

Entonces la pregunta es: ¿Debo realmente registrar todo, incluso si no es una gran aplicación empresarial? Debido a que estas bibliotecas, obviamente, no necesitan ningún registro, a excepción de los mensajes de error. Y mi experiencia muestra que los registradores son una herramienta terrible para la depuración. ¿Por qué debería usarlo?

Answer 1

¿Cómo saber cuándo es demasiado el registro? Cuando sabe que la información registrada no es importante a largo plazo, ya sea para acciones de depuración o corrección de errores, o la aplicación no trata con demasiada información importante.

A veces tiene que registrar casi todo. ¿El rendimiento o la posibilidad total de análisis es la parte más importante de una aplicación? Realmente depende.

He trabajado en el pasado con una cierta integración con muchos servicios web diferentes, como 10 en una misma aplicación. Registramos todas las solicitudes y respuestas de xml. ¿Es esto una sobrecarga? A largo plazo, no lo creo porque trabajamos con muchas operaciones de tarjetas de crédito y deberíamos tener todos los procesos realizados con el servidor conectado. ¿Cómo saber qué pasó cuando hubo un error?

No creería lo que vi en algunas de las respuestas xml. Incluso recibí un xml sin cerrar las etiquetas de una GRAN compañía de aviones. ¿Fueron los "registros excesivos" una mala práctica? Dígalo a sus clientes cuando tengan que demostrar que el error provino del otro proveedor.

Answer 2

Idealmente, utiliza un registrador que permite niveles de registro; log4j tiene fatal/error/warn/debug/info, por ejemplo. De esta forma, si configura el nivel para "solo mostrar errores", no perderá velocidad en los mensajes de registro de creación de software que no necesitaba.

Dicho esto, es solo demasiado registro hasta que termines necesitando algo que se habría registrado. Sin embargo, parece que la mayoría de los registros que le están ralentizando deberían ser de nivel "traza"; te está mostrando lo que un perfilador tendría.

Answer 3

Depende, es este código para una aplicación o una biblioteca? Para una aplicación, el registrador es útil una vez que el código está en producción. No debe usarse para depurar, sino para ayudarlo a replicar un error. Cuando un usuario le dice que su aplicación se bloqueó, siempre quiere la máxima información de registro.

Estoy de acuerdo en que hace que el código sea menos legible. ¡Incluso hace que la aplicación sea más lenta!

Es un juego totalmente diferente para una biblioteca. Debería tener un registro constante con el nivel adecuado. La biblioteca DEBERÍA informar al equipo de desarrollo cuando ocurra un error.

Answer 4

El registro debe proporcionarle la información que una traza de pila no puede para localizar un problema. Esto generalmente significa que la información es algún tipo de rastro histórico de lo que hizo el programa, a diferencia del estado en el que se encuentra en el momento del error.

Se ignorarán demasiados datos históricos. Si puede deducir con seguridad que se llamó a un método sin tener que registrar realmente su entrada y salida, entonces es seguro eliminar esas entradas de registro.

Otro signo negativo es si sus archivos de registro comienzan a utilizar una gran cantidad de espacio en disco. No solo estás sacrificando espacio, probablemente vas a ralentizar la aplicación demasiado.

Answer 5

Para responder a la pregunta, ¿por qué debería usar los registradores?

¿Alguna vez ha encontrado un software en el que el único error indicado presentado al usuario final es Fatal error occured. ¿No sería bueno averiguar qué lo causó?

El registro es una herramienta que realmente puede ayudarlo a reducir este tipo de problemas en el campo. Recuerde, los sistemas de usuario final no tienen IDE agradables para depurar y los usuarios finales generalmente no están lo suficientemente informados como para ejecutar estas herramientas. Sin embargo, los usuarios finales, en la mayoría de los casos, son capaces de copiar archivos de configuración de registro (escritos por nosotros, programadores inteligentes) en una ubicación predefinida y recuperar archivos de registro y enviarlos por correo electrónico (plantas pobres por tener que analizar megabytes de salida de registro) cuando ellos encuentran problemas

Habiendo dicho esto, el registro debe ser altamente configurable y en condiciones normales producir un rendimiento mínimo. Además, los guardias deben proteger el registro de nivel más fino para que no consuma demasiados recursos.

Creo que en el ejemplo que ha proporcionado todos los registros se deberían haber hecho en un nivel TRACE. Además, dado que no puede pasar nada malo entre el punto de entrada de la función y la salida, probablemente tenga sentido tener allí solo una declaración de registro.

Answer 6

mayoría de las bibliotecas de registro incorporan un medio para confirmar que el registro está habilitado antes de procesar una instrucción:

Por ejemplo:

public void foo(ComplicatedObject bar) { 
    Logger.getInstance(Foo.class).trace("Entering foo(" + bar + ")"); 
} 

Podría ser muy costoso dependiendo de la eficacia de la bar.toString() método. Sin embargo, si en lugar de envolver que en un cheque por el nivel de registro antes de realizar la concatenación de cadenas:

static { 
    Logger log = Logger.getInstance(Foo.class); 

public void foo(ComplicatedObject bar) { 
    if (log.isTraceEnabled()) { 
     log.trace("Entering foo(" + bar + ")"); 
    } 
} 

A continuación, la concatenación de cadenas sólo se produce si al menos una appender para la clase se establece a Trace. Cualquier mensaje de registro complicado debería hacer esto para evitar la creación de cadenas innecesarias.

Answer 7

A lo largo de los años me he inclinado hacia adelante y hacia atrás entre la promoción de iniciar sesión todo en los niveles adecuados (seguimiento, información, etc.) y pensando que cualquiera es una completa pérdida de tiempo. En realidad, depende de lo que será útil rastrear o requerir (el registro puede ser una forma económica de mantener un registro de auditoría).

Personalmente, tiendo a registrar la entrada/salida en un componente o nivel de servicio y luego registro puntos significativos en el proceso, como una decisión de lógica de negocios o una llamada a otro servicio/componente. Por supuesto, los errores siempre se registran, pero solo una vez y en el lugar donde se manejaron (el seguimiento de pila y el mensaje de excepción deben tener suficiente información para diagnosticar el problema) y cualquier interfaz de servicio/componente siempre debe manejar un error (incluso si es convirtiéndolo en otro más apropiado para la persona que llama).

El problema con el registro de cosas por si algo sale mal es que terminas con demasiada información que es imposible identificar el problema, especialmente si se está ejecutando bajo un servidor ya que terminas con un montón de entrelazados entradas de registro. Obviamente, puedes evitar eso incorporando una identificación de solicitud en la entrada y usando algún software para filtrar eso. Por supuesto, también tiene el caso donde su aplicación se distribuye y/o agrupa y tiene múltiples registros.

En la actualidad, nunca escribo el código de entrada/salida de entradas, el código simplemente se pone en el camino y es mucho más fácil usar algo como aspectj si realmente se necesita. Usar aspectj también garantizaría ser consistente (puede cambiar el formato de registro en un solo lugar en lugar de tener que cambiar todas las operaciones) y preciso (en caso de que alguna refactorización agregue un nuevo parámetro y el desarrollador se olvide de agregarlo al registro).

Una cosa que he pensado hacer o mirar para ver si alguien ya tiene un registrador que almacenará las entradas en la memoria, entonces si se encuentra un error, se escriben, si la operación tiene éxito las entradas se descartan. Si alguien sabe de uno (idealmente para log4j) por favor hágamelo saber, alternativamente tengo algunas ideas sobre cómo implementar esto si alguien está interesado en hacer uno.

Answer 8

Este nivel de registro es canónicamente malo, de hecho, vi el código exactly like this en la Daily WTF hace unos días.

Pero el registro es en general una muy buena cosa.