Como você log erros do servidor em sites de Django

votos
163

Então, quando se joga com o desenvolvimento I pode apenas definir settings.DEBUGa Truee se um erro occures eu posso vê-lo bem formatada, com uma boa stack trace e informações pedido.

Mas no tipo de local de produção Eu prefiro usar DEBUG=Falsee visitantes da mostra alguma página de erro 500 standard com informações que eu estou trabalhando para corrigir este erro, neste momento;)
Ao mesmo tempo, eu gostaria de ter alguma forma de registrar tudo as informações (rastreamento de pilha e informações do pedido) para um arquivo no meu servidor - para que eu possa apenas saída para o meu console e assistir erros rolar, enviar e-mail o log para me a cada hora ou algo assim.

Que soluções logging você recomendo para uma django local, que atendesse a esses requisitos simples? Eu tenho o aplicativo em execução como fcgiservidor e estou usando o servidor web Apache como frontend (embora pensando em ir para lighttpd).

Publicado 26/10/2008 em 15:37
fonte usuário
Em outras línguas...                            


6 respostas

votos
92

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

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

Seu process_exception()método pode, em seguida, executar qualquer tipo de log que você gostaria: escrever para consolar, escrevendo para um arquivo, etc., etc.

Edit: embora seja um pouco menos útil, você também pode ouvir o got_request_exceptionsinal, que será enviada sempre que uma exceção é encontrado durante o processamento do pedido:

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

Isso não lhe dar acesso ao objeto de exceção, no entanto, assim que o método middleware é muito mais fácil de trabalhar.

Respondeu 26/10/2008 em 15:53
fonte usuário

votos
75

Django Sentry é um bom caminho a percorrer, como já mencionado, mas há um pouco de trabalho envolvido na sua criação adequadamente (como um site separado). Se você só quer registrar tudo em um arquivo de texto simples aqui é a configuração de registo para colocar em seusettings.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
        },
    },
}
Respondeu 18/06/2011 em 12:58
fonte usuário

votos
40

django-db-log, mencionados numa outra resposta, foi substituído com:

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

Respondeu 16/11/2010 em 21:34
fonte usuário

votos
30

Obviamente James é correto, mas se você queria exceções ingresse em um armazenamento de dados, existem algumas soluções open source já estão disponíveis:

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

2) Db-Log é uma boa escolha, bem como: http://code.google.com/p/django-db-log/

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

Eu usei tanto e eles funcionam bem.

Respondeu 27/10/2008 em 14:33
fonte usuário

votos
13

Algum tempo se passou desde a submissão de código mais útil do EMP. Eu só agora implementado, e enquanto debatendo com alguma opção manage.py, para tentar perseguir um bug, eu tenho um aviso depreciação no sentido de que com a minha versão atual do Django (1,5.?) Um filtro require_debug_false é agora necessário para o manipulador mail_admins.

Aqui está o código revisto:

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
        },
    },
}
Respondeu 09/10/2013 em 09:51
fonte usuário

votos
1

Eu só tinha um problema chato com o meu fcgiscript. Ocorreu antes django sequer começou. A falta de log é tão dolorosa. De qualquer forma, redirecionando stderr para um arquivo como a primeira coisa que ajudou muito:

#!/home/user/env/bin/python
sys.stderr = open('/home/user/fcgi_errors', 'a')
Respondeu 23/08/2016 em 16:33
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more