Pregunta

Tengo un sitio corriendo en Django. Frontend es lighttpd y usa fcgi para alojar django.

Comienzo mis procesos fcgi de la siguiente manera:

python2.6 /<snip>/manage.py runfcgi maxrequests=10 host=127.0.0.1 port=8000 pidfile=django.pid

Para el registro, tengo un RotatingFileHandler definido de la siguiente manera:

file_handler = RotatingFileHandler(filename, maxBytes=10*1024*1024, backupCount=5,encoding='utf-8')

El registro está funcionando. Sin embargo, parece que los archivos se están rotando cuando ni siquiera llegan a 10Kb, y mucho menos a 10Mb. Mi conjetura es que cada instancia de fcgi solo está manejando 10 solicitudes y luego reapareciendo. Cada reaparición de fcgi crea un nuevo archivo. Confirmo que fcgi se está iniciando bajo un nuevo identificador de proceso cada cierto tiempo (es difícil decir la hora exactamente, pero en menos de un minuto).

¿Hay alguna manera de evitar estos problemas? Me gustaría que todas las instancias de fcgi se registren en un archivo hasta que alcance el límite de tamaño, momento en el que se realizará la rotación del archivo de registro.

¿Fue útil?

Solución

Como dijo Alex, el registro es seguro para subprocesos, pero los controladores estándar no se pueden usar de manera segura para registrar desde múltiples procesos en un solo archivo.

ConcurrentLogHandler utiliza el bloqueo de archivos para permitir el registro desde múltiples procesos.

Otros consejos

En tus zapatos me cambiaría a TimedRotatingFileHandler - - Me sorprende que los manejadores de archivos rotativos basados ??en el tamaño estén dando este problema (ya que debería ser inmune a los procesos que producen las entradas del registro), pero la versión cronometrada (aunque no se controla exactamente en el parámetro que usted prefiere) debería resolver eso. O bien, escriba su propio controlador de archivos giratorio más sólido (puede tomar mucho de las fuentes de la biblioteca estándar) para que se asegure de que los distintos procesos no sean un problema (como nunca deberían ser).

Como parece que está usando el modo de apertura de archivo predeterminado de adjuntar (" a ") en lugar de escribir (" w "), si un proceso vuelve a aparecer, debe agregarse al archivo existente, luego se reinicia cuando Se alcanza el límite de tamaño. Por lo tanto, no estoy seguro de que lo que se está viendo se deba a un reabastecimiento de los procesos CGI. (Por supuesto, esto supone que el nombre del archivo permanece igual cuando el proceso vuelve a aparecer).

Aunque el paquete de registro es seguro para subprocesos, no maneja el acceso simultáneo al mismo archivo desde múltiples procesos, porque no hay una forma estándar de hacerlo en la stdlib. Mi consejo habitual es configurar un proceso de daemon separado que implemente un servidor de socket y registre los eventos recibidos a través de él para archivar, los otros procesos simplemente implementan un SocketHandler para comunicarse con el daemon de registro. Entonces todos los eventos se serializarán en el disco correctamente. La documentación de Python contiene un trabajo servidor socket que podría servir como base para esta necesidad.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top