Como você registra erros do servidor em sites django

Question

Então, ao brincar com o desenvolvimento, posso simplesmente definir settings.DEBUG para True E se ocorrer um erro, posso vê -lo bem formatado, com um bom rastreamento de pilha e solicitar informações.

Mas em um tipo de site de produção, eu prefiro usar DEBUG=False e mostre aos visitantes alguma página de erro padrão 500 com informações que estou trabalhando para corrigir este bug neste momento;)
Ao mesmo tempo, gostaria de ter alguma maneira de registrar todas essas informações (pilha de rastreamento e solicitar informações) a um arquivo no meu servidor - para que eu possa apenas emití -las no meu console e assistir erros rolando, envie um e -mail para mim Cada hora ou algo assim.

Que soluções de registro você recomendaria para um Django-Site, que atenderia a esses requisitos simples? Eu tenho o aplicativo em execução como fcgi Servidor e estou usando o Apache Web Server como front -end (embora pensando em ir para o LightTPD).

Answer 1

Bem, quando DEBUG = False, Django enviará automaticamente um rastreamento completo de qualquer erro para cada pessoa listada no ADMINS Configuração, o que recebe as notificações de graça. Se você quiser um controle mais refinado, pode escrever e adicionar às suas configurações uma classe de middleware que define um método chamado process_exception(), que terá acesso à exceção que foi levantada:

http://docs.djangoproject.com/en/dev/topics/http/middleware/#process-exception

Sua process_exception() O método pode então executar qualquer tipo de registro que você desejar: escrever para consolar, escrever em um arquivo, etc. etc.

Editar: Embora seja um pouco menos útil, você também pode ouvir o got_request_exception sinal, que será enviado sempre que uma exceção for encontrada durante o processamento de solicitação:

http://docs.djangoproject.com/en/dev/ref/signals/#got-request-exception

Isso faz não Dê acesso ao objeto de exceção, no entanto, para que o método do middleware seja muito mais fácil de trabalhar.

Answer 2

O Django Sentry é um bom caminho a percorrer, como já mencionado, mas há um pouco de trabalho envolvido na configuração corretamente (como um site separado). Se você deseja apenas registrar tudo em um arquivo de texto simples, aqui está a configuração de log para colocar em seu settings.py

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        # Include the default Django email handler for errors
        # This is what you'd get without configuring logging at all.
        'mail_admins': {
            'class': 'django.utils.log.AdminEmailHandler',
            'level': 'ERROR',
             # But the emails are plain text by default - HTML is nicer
            'include_html': True,
        },
        # Log to a text file that can be rotated by logrotate
        'logfile': {
            'class': 'logging.handlers.WatchedFileHandler',
            'filename': '/var/log/django/myapp.log'
        },
    },
    'loggers': {
        # Again, default Django configuration to email unhandled exceptions
        'django.request': {
            'handlers': ['mail_admins'],
            'level': 'ERROR',
            'propagate': True,
        },
        # Might as well log any errors anywhere else in Django
        'django': {
            'handlers': ['logfile'],
            'level': 'ERROR',
            'propagate': False,
        },
        # Your own app - this assumes all your logger names start with "myapp."
        'myapp': {
            'handlers': ['logfile'],
            'level': 'WARNING', # Or maybe INFO or DEBUG
            'propagate': False
        },
    },
}

Answer 3

Django-DB-Log, mencionado em outra resposta, foi substituído por:

https://github.com/dcramer/django-sentry

Answer 4

Obviamente, James está correto, mas se você quiser registrar exceções em um armazenamento de dados, existem algumas soluções de código aberto já disponíveis:

1) Crashlog é uma boa escolha: http://code.google.com/p/django-crashlog/

2) DB-Log também é uma boa escolha: http://code.google.com/p/django-db-log/

Qual é a diferença entre os dois? Quase nada que eu possa ver, então qualquer um será suficiente.

Eu usei os dois e eles funcionam bem.

Answer 5

Algum tempo se passou desde o envio de código mais útil da EMP. Acabei de implementá -lo agora e, enquanto me debatendo com alguma opção gerencial.py, para tentar perseguir um bug, recebi um aviso de depreciação no sentido de que, com minha versão atual do Django (1.5.?) Um requent_debug_false filtro está agora Necessário para o manipulador Mail_Admins.

Aqui está o código revisado:

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'filters': {
         'require_debug_false': {
             '()': 'django.utils.log.RequireDebugFalse'
         }
     },
    'handlers': {
        # Include the default Django email handler for errors
        # This is what you'd get without configuring logging at all.
        'mail_admins': {
            'class': 'django.utils.log.AdminEmailHandler',
            'level': 'ERROR',
            'filters': ['require_debug_false'],
             # But the emails are plain text by default - HTML is nicer
            'include_html': True,
        },
        # Log to a text file that can be rotated by logrotate
        'logfile': {
            'class': 'logging.handlers.WatchedFileHandler',
            'filename': '/home/username/public_html/djangoprojectname/logfilename.log'
        },
    },
    'loggers': {
        # Again, default Django configuration to email unhandled exceptions
        'django.request': {
            'handlers': ['mail_admins'],
            'level': 'ERROR',
            'propagate': True,
        },
        # Might as well log any errors anywhere else in Django
        'django': {
            'handlers': ['logfile'],
            'level': 'ERROR',
            'propagate': False,
        },
        # Your own app - this assumes all your logger names start with "myapp."
        'myapp': {
            'handlers': ['logfile'],
            'level': 'DEBUG', # Or maybe INFO or WARNING
            'propagate': False
        },
    },
}

Answer 6

Eu só tive um problema irritante com o meu fcgi roteiro. Ocorreu antes mesmo de Django começar. A falta de exploração madeireira é tão dolorosa. De qualquer forma, redirecionar Stderr para um arquivo, pois a primeira coisa ajudou muito:

#!/home/user/env/bin/python
sys.stderr = open('/home/user/fcgi_errors', 'a')