Django e fcgi - logging questão

Question

Eu tenho um site rodando em Django. Frontend é lighttpd e está usando fcgi para django host.

Eu começo meus processos fcgi da seguinte forma:

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

Para o log, eu tenho um RotatingFileHandler definidos da seguinte forma:

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

O registro está funcionando. No entanto, parece que os arquivos estão girando quando eles nem sequer chegar até 10Kb, muito menos 10Mb. Meu palpite é que cada instância fcgi única está a lidar com 10 pedidos, e então re-desova. Cada reaparecimento de fcgi cria um novo arquivo. Confirmo que fcgi está iniciando sob nova ID de processo de cada tantas vezes (difícil de dizer o tempo exatamente, mas menos de um minuto).

Existe alguma maneira de contornar este problemas? Eu gostaria todas as instâncias fcgi log para um arquivo até que ele atinja o limite de tamanho, altura em que uma rotação de arquivo de log que aconteceria.

Answer 1

Como Alex disse, o registo é thread-safe, mas os manipuladores padrão não pode ser usado com segurança para iniciar sessão a partir de vários processos em um único arquivo.

ConcurrentLogHandler usa o bloqueio de arquivos para permitir o registo de dentro vários processos.

Answer 2

Em seus sapatos eu mudar para um TimedRotatingFileHandler - - estou surpreso que o tamanho base rotativa identificadores de arquivo está dando este problema (como deveria ser imune a processos que estão produzindo as entradas de log), mas a versão cronometrada (embora não controlados sobre exatamente o parâmetro que você preferir) deve resolver isto. Ou, escreva seu próprio manipulador de arquivo, mais sólida, girando (você pode ter um monte de fontes da biblioteca padrão) que garante processos diferentes não são um problema (como eles nunca devem ser).

Answer 3

Como você parece estar usando o modo de abertura de arquivo padrão de adição ( "a") em vez de gravação ( "w"), se um processo de re-spawns que deverá ser anexada ao arquivo existente, em seguida, rollover quando o limite de tamanho é atingido. Então, eu não estou certo de que o que você está vendo é causada por processos CGI desova re-. (Isto naturalmente pressupõe que o nome do arquivo continua a ser o mesmo quando o processo de re-desova).

Embora o pacote de logging é thread-safe, ele não controla o acesso simultâneo ao mesmo arquivo de vários processos - porque não há nenhuma maneira padrão de fazê-lo no stdlib. Meu conselho normal é a criação de um processo de daemon separado que implementa um servidor e registos de soquete eventos recebidos através dele para o arquivo - os outros processos em seguida, basta implementar uma SocketHandler se comunicar com o daemon de registro. Em seguida, todos os eventos vai ser serializado para o disco corretamente. A documentação Python contém um trabalho tomada servidor que poderia servir de base para esta necessidade.