¿Cuál es su estrategia para escribir registros en su software para hacer frente a una cantidad ENORME de mensajes de registro?

Question

Gracias por su tiempo y lo siento por este largo mensaje!

Mi ambiente de trabajo

Linux C/C++ (pero soy nuevo en plataforma Linux)

Mi pregunta en breve

En el software que estoy trabajando escribimos un montón de mensajes de registro a los archivos locales que hacen que el tamaño del archivo crezca rápidamente y finalmente agota todo el espacio en disco (¡ay!). Queremos estos mensajes de registro para la resolución de fallas, especialmente después de que el software se haya lanzado al sitio del cliente. Creo que, por supuesto, es inaceptable ocupar todo el espacio en disco de la computadora del cliente, , pero no tengo una buena idea de cómo manejar este. Entonces Me pregunto si alguien tiene alguna buena idea aquí. Más información va abajo

Lo que NO estoy preguntando

1). Estoy NO solicitando una biblioteca de registro de C++ recomendada. Nosotros escribimos un registrador nosotros mismos.

2). Estoy NO preguntando qué detalles (como marca de tiempo, ID de hilo, nombre de función, etc.) deben escribirse en un mensaje de registro. Se pueden encontrar algunas sugerencias here.

Lo que he hecho en mi software

separo los mensajes de registro en 3 categorías:

• SISTEMA: Sólo ingrese los pasos importantes en mi software. Ejemplo: una invocación externa al método de interfaz de mi software. La idea detrás de estos mensajes es que pudimos ver lo que generalmente está sucediendo en el software. Hay no hay muchos mensajes.

• ERROR: solo registre las situaciones de error, como que no se encuentre una ID. Por lo general, no son muchos tales mensajes.

• INFORMACIÓN: Registre los pasos detallados que se ejecutan dentro de mi software. Por ejemplo, cuando se llama a un método de interfaz, se escribe un mensaje de registro del sistema como se menciona anteriormente, y la rutina de llamada completa en los módulos internos dentro del método de interfaz se grabará con mensajes INFO. La idea detrás es que estos mensajes podrían ayudarnos a identificar la pila de llamadas detallada para la solución de problemas o la depuración. Esta es la fuente del problema use-up-disk-space: Siempre hay TAN MUCHOS mensajes INFO cuando el software se ejecuta normalmente.

Mis intentos y pensamientos

1). Intenté no grabar ningún mensaje de registro INFO. Esto resuelve el problema de espacio en disco pero también pierdo mucha información para la depuración.Piense en esto: Mi cliente está en una ciudad diferente y es caro ir allí a menudo. Además, usan una intranet que es 100% inaccesible desde el exterior. Por lo tanto: no siempre podemos enviar ingenieros en el sitio tan pronto como encuentren problemas; no podemos iniciar una sesión de depuración remota. Por lo tanto, los archivos de registro, creo, son la única forma en que podríamos utilizar para descubrir la raíz del problema.

2). Tal vez podría hacer la estrategia de registro configurable en tiempo de ejecución (actualmente es antes de que se ejecute el software), es decir: en tiempo de ejecución normal, el software solo registra registros de SISTEMA y ERROR; cuando surge un problema, alguien puede cambiar la configuración de registro para que los mensajes INFO puedan registrarse. Pero aún así: ¿quién podría cambiar la configuración en tiempo de ejecución? Tal vez deberíamos educar al administrador de software?

3). Tal vez siempre podría activar el inicio de sesión del mensaje INFO pero empacar periódicamente los archivos de registro en un paquete comprimido. Hmm ...

Finalmente ...

¿Cuál es su experiencia en sus proyectos/trabajo? ¡Cualquier pensamiento/idea/comentario es bienvenido!

EDITAR

Gracias por todo su esfuerzo !!! Aquí hay un resumen de los puntos clave de todas las respuestas a continuación (y voy a intentarlo):

1). No use archivos de registro grandes. Use los relativamente pequeños.

2). Trate periódicamente con los más antiguos (elimínelos o zip y colóquelos en un almacenamiento más grande).

3). Implementar una estrategia de registro configurable en tiempo de ejecución.

Answer 1

hay dos cosas importantes a tomar nota de:

• archivos de gran tamaño son difíciles de manejar. Son difíciles de transmitir, difícil de investigar, ...
• Los archivos de registro son principalmente texto, y el texto es compresible

En mi experiencia, una forma sencilla de hacer frente a esto es:

• Solo escriba archivos pequeños: comience un nuevo archivo para una nueva sesión o cuando el archivo actual crezca más allá de un límite preestablecido (he encontrado que 50 MB son bastante efectivos). Para ayudar a ubicar el archivo en el que se han escrito los registros, haga que la fecha y hora de creación sean parte del nombre del archivo.
• Comprima los registros, ya sea sin conexión (una vez que el archivo está terminado) o en línea (sobre la marcha).
• Ponga en marcha una rutina de limpieza, elimine todos los archivos anteriores a X días o cada vez que llegue a más de 10, 20 o 50 archivos, elimine el más antiguo.

Si desea mantener los registros System y Error más largo, es posible que duplicarlos en un archivo específico giratoria que sólo un seguimiento de ellos.

Poner en conjunto, esto da la siguiente carpeta de registro:

Log/ 
    info.120229.081643.log.gz // <-- older file (to be purged soon) 
    info.120306.080423.log // <-- complete (50 MB) file started at log in 
           (to be compressed soon) 
    info.120306.131743.log // <-- current file 

    mon.120102.080417.log.gz // <-- older mon file 
    mon.120229.081643.log.gz // <-- older mon file 
    mon.120306.080423.log // <-- current mon file (System + Error only) 

Dependiendo de si se puede programar (cron) la tarea de limpieza, puede simplemente girar un hilo para la limpieza dentro de su aplicación. Ya sea que elija una fecha de purga o una cantidad limitada de archivos, es una elección que debe hacer, ya sea que sea efectiva.

Nota: por experiencia, un peso de 50MB pesa alrededor de 10MB cuando se comprime sobre la marcha y menos de 5MB cuando se lo comprime fuera de línea (sobre la marcha es menos eficiente).

Answer 2

Me

a) Elevar el nivel de detalle de los mensajes de registro configurables en tiempo de ejecución. b) Crea un nuevo archivo de registro para cada día. A continuación, puede obtener cron para comprimirlos y/o eliminarlos o tal vez transferirlos a almacenamiento de información.

Answer 3

Su (3) es una práctica estándar en el mundo del registro de sistema UNIX.

1. Cuando el archivo de registro alcanza una cierta edad o el tamaño máximo, iniciar una nueva
2. postal o de otra manera comprimir el viejo
3. tirar el enésimo registro comprimido más antiguo

Answer 4

Una forma lidiar con esto es rotar los archivos de registro.

Inicie el inicio de sesión en un archivo nuevo una vez que alcanza cierto tamaño y conserva los últimos dos archivos de registro antes de comenzar a sobrescribir el primero.

No tendrá toda la información posible, pero tendrá al menos algunas cosas previas al problema.

La estrategia de registro parece inusual pero tiene sus razones.

Answer 5

Mi respuesta es escribir registros largos y luego twittear la información que desee.

comprimirlos en una base diaria - pero de manera durante una semana

Answer 6

me gusta registra una gran cantidad. En algunos programas, mantuve las últimas n líneas en la memoria y las escribí en el disco en caso de error o cuando el usuario solicita asistencia técnica.

En un programa, mantendría las últimas 400 líneas en la memoria y las guardará en una base de datos de registro cuando se produzca un error. Un servicio por separado monitoreó esta base de datos y envió una solicitud HTTP que contenía información resumida a un servicio en nuestra oficina que lo agregó a una base de datos allí.

Teníamos un programa en cada una de nuestras máquinas de escritorio que mostraba una lista (actualizada por F5) de problemas, que podíamos asignarnos y marcar como procesados. Pero ahora me estoy dejando llevar :)

Esto funcionó muy bien para ayudarnos a dar soporte a muchos usuarios en varios clientes. Si se produce un error en un PDA en algún lugar con nuestro software, en un minuto aproximadamente obtendríamos un nuevo elemento en nuestras pantallas. A menudo telefoneábamos a un usuario antes de que se dieran cuenta de que tenían un problema.

Teníamos un mecanismo de filtrado para procesar automáticamente o asignar problemas que sabíamos que habíamos solucionado o que no nos importaban demasiado.

En otros programas he tenido archivos por hora o diarios que se eliminan después de n días, ya sea por el programa en sí o por un servicio dedicado de limpieza de registros.