¿Mejores prácticas para el registro de Java desde varios subprocesos?

Question

Quiero tener un registro de diagnóstico producido por varias tareas de administración de datos. Estas tareas pueden estar en múltiples hilos. Cada tarea necesita escribir un elemento (posiblemente con subelementos) en el registro; entrar y salir rápidamente. Si se tratara de una situación de una sola tarea, utilizaría XMLStreamWriter ya que parece ser la mejor opción para la simplicidad/funcionalidad sin tener que mantener un documento XML expandido en la memoria.

Pero no es una situación de una sola tarea, y no estoy seguro de cómo asegurarme de que es "seguro para hilos", donde "enhebrar" en esta aplicación significa que cada elemento de registro debe escribirse correctamente en el registro en serie (uno después del otro y no intercalado de ninguna manera).

¿Alguna sugerencia? Tengo una vaga intuición de que el camino a seguir es usar una cola de elementos de registro (con cada uno de ellos capaz de producirse rápidamente: mi aplicación está ocupada haciendo un trabajo real que es sensible al rendimiento), y tengo un hilo separado que maneja el registro elementos y los envía a un archivo para que el registro no interrumpa a los productores.

El registro no tiene que ser necesariamente XML, pero sí quiero que sea estructurado y legible por máquina.

editar: puse "threadsafe" entre comillas. Log4j parece ser la opción obvia (nueva para mí pero antigua para la comunidad), ¿por qué reinventar la rueda?

Answer 1

Utilice un marco de registro, como Log4j.

Answer 2

Puede usar mecanismos de sincronización (como un monitor o un semáforo) para asegurarse de que se procesa una solicitud de registro antes de aceptar la siguiente. Todo esto podría estar oculto del código que llama a las rutinas de registro.

Answer 3

Utilice un marco de registro, como Log4.

y si no está contento con la salida puede escribir su propio apéndice, filtro, lo que sea que lo ajuste simplemente escriba. Así que podrías hacer incluso un caché para reorganizar las entradas, aunque no estoy diciendo que sea una buena idea.

Answer 4

log4j es y ha sido el estándar para el registro de Java durante muchos años. Pero si no le apetece una dependencia externa, el paquete java.util.logging proporciona una solución aceptable.

Answer 5

Utilice un marco de registro que implemente alguna forma de the NDC pattern, como Log4J.

Answer 6

Desarrollar esto usted mismo de una manera segura para la ejecución de subprocesos no es trivial, por lo que realmente debería usar un marco de trabajo de registro existente que sea seguro para subprocesos. El más utilizado es Log4J, que es seguro para subprocesos (ver FAQ).

Answer 7

Creo que estás en el camino equivocado. Usted dice "threadsafe" pero en realidad quiere decir "serializado". Threadsafe significa que un hilo no interferirá con los datos de otro hilo. La mayoría de las veces, los problemas de enhebrado se resuelven de antemano y no debe preocuparse solo por el registro. Por ejemplo, si su escritura:

myVariableSum = 0 + myVariable; 
//here comes other thread - Not very likely! 
logger.info("Log some INFO; myVariable has value" + myVariable.toString()); 

Usted tiene que asegurarse de que myVariable no ha sido cambiado por algún otro flujo del cálculo momento (primera línea) se ha realizado, pero antes de iniciar método fue llamado. Si esto ocurre, registrará el valor sucio que no se utilizó para realizar la operación, pero el valor fue asignado por otro hilo.Esto generalmente es cuidado; por ejemplo, la variable local (nivel de método) no se puede cambiar por otro hilo. De todos modos, si tiene que preocuparse por esto al iniciar sesión, más del 99% de que su programa ya tiene problemas graves de enhebrado.
Todos los principales frameworks de registro son en sí mismos "threadsafe", lo que significa que pueden implementarse en entornos multiproceso y no mostrarán problemas similares a los descritos internamente.
Obtener rastros para que aparezcan en el registro para que sucedan se suele llamar "serialización" de llamadas. La serialización de las escrituras de registro será un importante cuello de botella de rendimiento en cualquier aplicación multiproceso. Si usa el marco de trabajo de registro, como log4j, los rastros de todos los hilos aparecerán en un solo lugar más o menos para que sucedan. Sin embargo, una columna generalmente es un nombre de subproceso, por lo que puede filtrar fácilmente sus datos de registro por hilo; cada hilo registrará sus datos en orden cronológico. Echa un vistazo a este enlace: http://logging.apache.org/log4j/1.2/faq.html#1.7
Por último, si serializar grabaciones de registro es lo que realmente necesitas, entonces podrías usar algún tipo de estructura, como java.util.concurrent.BlockingQueue para enrutar tus mensajes.

Answer 8

Tiendo a usar SLF4J encima de Log4J. La funcionalidad parameterized logging es especialmente atractiva si va a tener muchas declaraciones de inicio de sesión que pueden desconectarse en un entorno de producción.

También puede ejecutarse en la parte superior de java.util.logging o usar su propia salida simple.

Answer 9

Utilice logback-classic. Es una implementación más nueva y mejor de log4j.

Answer 10

Si tuviera que hacerlo, podría hacer su propia versión ... utilizando FIFO o colas de único escritor/lector único.

Answer 11

Tuve un problema similar y demandas de implementación solo para registros especiales. Mi solución fue:

1. yo hicimos un blockinglinkedqueue con el tamaño de *2 de tráfico de la aplicación/min.

2. Todos los hilos colocan el objeto en la cola y finaliza el trabajo.

3. Separado Log-Writer hilo que toma el objeto de la cola y lo escribe en el archivo log4j usando un appender separado. Este appender no se usó para los registros del sistema.

Esto asegura que los registros se escriben en serie y siempre están en orden.

Esto no afectará el rendimiento de la aplicación ya que la escritura de registro es un proceso completamente separado y no creará un cuello de botella.

También puede usar aysncappender de log4j.