Comment enregistrer les erreurs de serveur sur les sites django ?

Question

Ainsi, lorsque je joue avec le développement, je peux simplement définir settings.DEBUG a True et si une erreur survient, je peux la voir joliment formatée, avec une bonne trace de la pile et des informations sur la demande.

Mais sur un site de production, je préférerais utiliser DEBUG=False et montrer aux visiteurs une page d'erreur 500 standard avec l'information que je travaille sur la correction de ce bug en ce moment ;)
En même temps, j'aimerais avoir un moyen de consigner toutes ces informations (trace de pile et informations sur les requêtes) dans un fichier sur mon serveur - de sorte que je puisse simplement les afficher dans ma console et regarder les erreurs défiler, m'envoyer le journal par courriel toutes les heures ou quelque chose comme ça.

Quelles solutions de journalisation recommanderiez-vous pour un site django, qui répondrait à ces simples exigences ? L'application est exécutée en tant que fcgi et j'utilise un serveur web apache comme frontal (bien que je pense passer à lighttpd).

Answer 1

Eh bien, quand DEBUG = False Django enverra automatiquement une trace complète de toute erreur à chaque personne figurant dans la liste de l'utilisateur. ADMINS qui vous permet d'obtenir des notifications presque gratuitement. Si vous souhaitez un contrôle plus fin, vous pouvez écrire et ajouter à vos paramètres une classe middleware qui définit une méthode appelée process_exception() qui aura accès à l'exception qui a été levée :

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

Votre process_exception() peut ensuite effectuer le type de journalisation que vous souhaitez : écriture sur la console, écriture dans un fichier, etc. etc.

Edit : bien que ce soit un peu moins utile, vous pouvez également écouter les got_request_exception qui sera envoyé chaque fois qu'une exception est rencontrée pendant le traitement de la demande :

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

Cela ne no vous donne toutefois accès à l'objet d'exception, de sorte que la méthode du middleware est beaucoup plus facile à utiliser.

Answer 2

Django Sentry est une bonne solution, comme nous l'avons déjà mentionné, mais sa mise en place correcte (en tant que site Web distinct) demande un peu de travail. Si vous voulez simplement enregistrer tout ce qui se passe dans un simple fichier texte, voici la configuration de l'enregistrement à mettre dans le fichier 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, mentionné dans une autre réponse, a été remplacé par :

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

Answer 4

De toute évidence, James a raison, mais si vous vouliez consigner les exceptions dans un datastore, il existe quelques solutions open source déjà disponibles :

1) CrashLog est un bon choix : http://code.google.com/p/django-crashlog/

2) Db-Log est également un bon choix : http://code.google.com/p/django-db-log/

Quelle est la différence entre les deux ? Presque rien que je puisse voir, donc l'un ou l'autre suffira.

J'ai utilisé les deux et ils fonctionnent bien.

Answer 5

Un certain temps s'est écoulé depuis la soumission du code le plus utile de l'EMP. Je viens juste de l'implémenter, et alors que je me débattais avec une option de manage.py, pour essayer de trouver un bug, j'ai reçu un avertissement de dépréciation indiquant qu'avec ma version actuelle de Django (1.5. ?) un filtre require_debug_false est maintenant nécessaire pour le gestionnaire mail_admins.

Voici le code révisé :

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
        },
    },
}