Django y fcgi - pregunta de registro

Question

Tengo un sitio ejecutándose en Django. Frontend es lighttpd y está usando fcgi para alojar django.

comienzo mi fcgi procesos 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 una RotatingFileHandler define como sigue:

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

El registro está funcionando. Sin embargo, parece que los archivos están girando cuando ni siquiera obtienen hasta 10 Kb, y mucho menos 10 Mb. Mi suposición es que cada instancia de fcgi solo está manejando 10 solicitudes, y luego vuelve a generar. Cada reaparición de fcgi crea un nuevo archivo. Confirmo que fcgi se está iniciando con la nueva identificación del proceso de vez en cuando (es difícil decir exactamente la hora, pero menos de un minuto).

¿Hay alguna forma de evitar este problema? Me gustaría que todas las instancias de fcgi inicien sesión en un archivo hasta que alcance el límite de tamaño, momento en el que se realizará la rotación de un archivo de registro.

Answer 1

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

ConcurrentLogHandler usa el bloqueo de archivos para permitir el inicio de sesión desde varios procesos.

Answer 2

En sus zapatos cambiaría a TimedRotatingFileHandler - Estoy sorprendido de que los manejadores de archivos rotativos basados ​​en tamaños estén dando este problema (ya que debe ser impermeable a los procesos que están produciendo las entradas de registro), pero el la versión temporizada (aunque no controlada exactamente en el parámetro que prefiera) debería resolverla. O bien, escriba su propio manejador de archivos más sólido y giratorio (puede tomar mucho de las fuentes de la biblioteca estándar) que garantiza que los procesos que varían no son un problema (como nunca deberían ser).

Answer 3

Como parece estar utilizando el modo de apertura de archivos predeterminado de append ("a") en lugar de escribir ("w"), si un proceso vuelve a generarlo, debe agregarlo al archivo existente, y luego se reinicia cuando el tamaño se alcanza el límite Así que no estoy seguro de que lo que está viendo sea causado por procesos de CGI que vuelven a generar. (Por supuesto, esto supone que el nombre del archivo sigue siendo el mismo cuando el proceso vuelve a generarse).

Aunque el paquete de registro es seguro para subprocesos, no maneja el acceso concurrente al mismo archivo desde múltiples procesos, porque no hay una forma estándar de hacerlo en stdlib. Mi consejo habitual es configurar un proceso de daemon independiente que implemente un servidor de socket y registre los eventos recibidos a través de él en el archivo; los otros procesos luego 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 working socket server que podría servir como base para esta necesidad.