¿Qué es un buen diseño para un archivo de registro de errores estándar?

Question

Estoy intentando diseñar el archivo de registro de error y advertencia para mi programa de escritorio.

Como mi programa lee el archivo de entrada del usuario, puede encontrar errores de sintaxis o datos inválidos de algún tipo. Una vez que se lee todo y el programa está procesando los datos, se pueden encontrar más problemas.

Quiero escribir mensajes sobre esto en un archivo de texto simple. También es posible que desee incluir texto informativo para indicar el progreso, el tiempo, el uso de la memoria, etc. Quiero incluir números de línea e incluso las líneas de entrada reales que están causando los errores.

Este será un archivo que el usuario querrá examinar, por lo que obviamente tiene que estar bien diseñado y ser fácil de usar.

¿Conoces alguna guía de estilo para esto, o has visto un archivo de registro de errores que te hizo pensar: "¡Ahora que es un archivo de registro bien diseñado!"

---

Seguimiento:

Las tres primeras respuestas son en realidad más aplicable para un registro del servidor o evento.

Realmente estoy buscando un formato para un archivo de registro para mi programa de escritorio para detallar cualquier problema que encuentre con el archivo de entrada y el éxito (o falla) de su procesamiento.

Estoy seguro de que hay algunas aplicaciones de escritorio que ha utilizado que producen tales archivos de registro. ¿Has visto alguno bueno?

Answer 1

syslog y log4j son formatos ampliamente utilizados con los que los administradores de sistemas pueden estar familiarizados, y hay herramientas para trabajar con ellos. Al menos debería mirarlos antes de hacer su propio formato.

Para Windows es casi siempre el Registro de eventos de la aplicación, que realmente no me gusta tanto como un archivo de texto, pero es la manera correcta. He visto algunas aplicaciones que escriben archivos de texto en su directorio de programa o algo así, pero siempre es ad hoc, nunca es estándar. McAfee VirusScan, por ejemplo, registra archivos en C: \ Documents and Settings \ All Users \ Application Data \ McAfee \ DesktopProtection. Mi máquina tiene muchos registros de instalación en C: \ Documents and Settings \ username \ Configuración local \ temp * .log y C: \ WINDOWS \ temp * .log. Pero, de nuevo, son todos diferentes y ad hoc y no están notablemente bien diseñados

Answer 2

Escribo registros en archivos csv y me resulta muy conveniente (puede usarlos como base de datos o abrirlos con un software de hoja de cálculo para un análisis sofisticado). El archivo de registro de ejemplo es:

Date;Time;Severity;TID;Module;This;Source;Message 
2010/01/21;08:47:05:205;DEBUG;4936;MAIN;0x00000000;DllMain@36;DLL_PROCESS_ATTACH 
2010/01/21;08:47:05:205;DEBUG;4936;MAIN;0x00000000;DllMain@40;DLL_PROCESS_DETACH 

no estoy seguro de si se adapta a sus necesidades, pero creo que tienes la idea principal. ¡Buena suerte!

Answer 3

Hay pocos archivos de registro que realmente me han impresionado; en realidad, me cuesta pensar en alguno (y no encuentro ninguno). En mi experiencia, los problemas que surgen se deben en parte a que los registros están formateados para que un interno (programador) los entienda, en lugar de entenderlos para otro programa o para un externo (no programador).

La información crucial a menudo se omite; a veces incluso información de fecha y hora. Yo recomendaría que sean fácilmente analizables; Usaría una notación ISO 8601 como '2010-01-22T10: 23: 21-08: 00' (incluida la zona horaria, nota). Incluiría la identificación del proceso (y del hilo); Consideraría incluir el nombre del programa, los argumentos (por ejemplo, el nombre del archivo); También incluiría el ID de usuario de alguna forma. Parte de esto solo podría necesitarse una vez por ejecución, pero podrían necesitarse otros bits para cada mensaje. Depende en parte de si el archivo de registro es único por ejecución o se comparte entre ejecuciones, y si un solo archivo puede ser utilizado por más de un usuario/proceso.

Luego debe decidir cómo va a identificar el contenido del mensaje y el final del contenido del mensaje. Especialmente para el análisis de máquina (pero también para el análisis sintáctico humano), es útil si el contenido tiene un formato inequívoco y el final se puede detectar. Es posible que necesite escapar del contenido (este es el paso que con mayor frecuencia se deshace, por lo que si el mensaje de error es sobre un mensaje de error mal formado, es realmente difícil saber qué datos hay del archivo y qué mensaje de error hay sobre los datos en el archivo).En un programa de subprocesos múltiples, o donde el archivo de registro puede compartirse entre procesos, debe tener en cuenta también cómo se almacenarán las escrituras, especialmente si tiene que tratar con líneas largas. Desea que cada mensaje se separe individualmente en el archivo de registro. Esto no es necesariamente trivial, incluso podría necesitar lidiar con un protocolo de bloqueo para garantizar el acceso controlado.

Considere si necesita proporcionar una bonita impresora para el registro.

Considere si un formato basado en XML (con etiquetas de inicio y fin) sería útil. No soy un gran admirador de XML, pero tiene algunas ventajas para el procesamiento de la máquina.