2010-10-05 21 views
9

Hay enorme números de hilos que se ejecutan en paralelo continuamente (supongamos que esta parte continua)). Todos los hilos desean registrar algunos datos de la aplicación, básicamente un conjunto de valores.¿Cómo registrar datos de múltiples hilos?

  1. ¿Cuál sería el mejor enfoque para registrar esta información? archivo único/múltiple?
  2. ¿Cuál sería el mejor enfoque para hacer una copia de seguridad de este registro?
  3. ¿Cuál sería el método para leer datos del archivo de respaldo y convertirlo en algo útil?

varios hilos como this y this sugieren log4net y log4j pero quieren saber el proceso real? ¿También cómo varios hilos escriben en el mismo archivo de registro? ¿Se requiere bloqueo de archivos para cada hilo? ¿Cómo funciona todo esto?

Cualquier puntero hacia la comprensión de todos los detalles sería apreciada.

Gracias.

+0

Normalmente, el método de registro se sincronizaría para que no tenga que preocuparse por acceder a él desde varios subprocesos. En cuanto a las copias de seguridad, existen copias ocultas en el sistema de archivos a nivel de la mayoría de los sistemas de archivos. Dudo que deba preocuparse por esto desde dentro de la aplicación. – Joey

+1

El objetivo de utilizar un marco de registro es exactamente que le evita preocuparse por todos esos detalles. –

+0

@Michael Borgwardt: Veo su punto, pero quiero saber los detalles. – understack

Respuesta

6

Una biblioteca como log4j se podrá configurar para sus necesidades.

  1. división en demasiados archivos hará que sea difícil para depurar algunos problemas, pero tener un archivo monolítico deja una sopa de procesos mixtos. Tendría un archivo para cada proceso atómico, es decir, un administrador de correo podría usar su propio archivo de registro. La información de depuración adicional para jdbc puede tener su propio archivo de registro, pero los errores y eventos importantes aún se informarán en el registro de la aplicación principal.

  2. Las principales bibliotecas de registro admiten la división y rotación de registros. Para una aplicación web bien utilizada, prefiero tener un archivo de registro hecho para cada día, y también dividir en un cierto tamaño. Puede crear un cron para comprimir los registros anteriores y, dependiendo de la aplicación, es posible que desee realizar una copia de seguridad de los mismos durante algunos meses o indefinidamente.

  3. En cuanto a la utilidad de depuración, puede grep para ciertas cadenas como "Excepción" para informar. Si busca estadísticas, debe hacer un registro para ese propósito específico además de su registro de proceso.

Los registros pueden ser síncronos o asíncronos, y este último suele ser mejor para el rendimiento. En general, se genera una cola de mensajes y luego se escribe mediante un hilo separado. Por lo tanto, varios hilos pueden escribir en esa cola o búfer en la memoria y un hilo bloqueará y escribirá el archivo. Está más o menos en segundo plano y no tienes que pensar en ello a menos que estés escribiendo una gran cantidad de datos.

+0

+1 por mencionar registros asíncronos –

1

En cuanto al punto 1, normalmente registro todo (relacionado con características) en el mismo archivo pero la línea de registro siempre incluye información de contexto que me permite rastrear (vía grep o algo más) el flujo del contexto/solicitud.

Ejemplo (un escenario de llamadas):

DEBUG|CallID#12: Establishing new AUDIO call from AA to BB 
DEBUG|CallID#34: Call accepted by ZZ at ... 
DEBUG|CallID#99: Call terminated by callee (SS) 

De esta manera es si alguien pregunta "¿qué le pasó a llamar de AA a BB a las 12:34 de hoy?" Simplemente grep de AA a BB (o el momento en que sucedió) y luego, una vez que obtengo la identificación de la llamada, obtener todos los detalles de la llamada es solo cuestión de volver a empastar con la identificación.

otras cosas como el chat, presencia, etc. iría en su propio archivo (no tendría mucho sentido para mezclar toda esta información en un solo archivo monolítico).

Si desea para cada subproceso (en lugar de por la acción/petición) acaba de registrar el nombre de la rosca que se realiza la acción.

relación al punto 2, la rotación diaria con log4j.

No estoy seguro de haber entendido el punto 3 ... ¿Quizás quiere decir analizar un archivo de registro para recuperar algunos patrones? Cualquier herramienta que soporte regex hará el truco (grep es el más útil).

+0

http://logging.apache.org/log4j/1.2/manual.html Desplácese hasta "Rendimiento". Debería darle algunas pistas. – biasedbit

1

Como los comentarios anteriores ya se dicen, existen marcos madereras precisamente para no tener que preocuparse acerca de tales detalles de bajo nivel. Log4J o sus sucesores como LogBack pueden manejar el registro de múltiples hilos de manera segura y efectiva. Simplemente diga a la estructura de registro qué registrar y dónde, y todo funciona (generalmente :-)

Para registrar datos específicos de subprocesos, puede considerar el uso de un contexto de diagnóstico. Esto earlier answer of mine lo explica con un ejemplo para Log4J. En Logback, se ha cambiado el nombre a Mapped Diagnostic Context.

En cuanto a las copias de seguridad y el postprocesamiento, todo depende de sus objetivos reales. Normalmente, todo lo que necesita son scripts simples o un solo comando como gzip y grep. Es difícil decir más sin información concreta.

Cuestiones relacionadas