Comment consignez-vous les erreurs de serveur sur les sites Django

Question

Ainsi, lorsque vous jouez avec le développement, je peux simplement définir settings.DEBUG sur True et si une erreur se produit, je la vois bien formatée, avec un bon suivi de pile et demander des informations.

Mais sur le type de site de production, je préfère utiliser DEBUG = False et montrer aux visiteurs une page d'erreur standard 500 contenant des informations sur lesquelles je travaille actuellement à la résolution de ce bogue;)
En même temps, j'aimerais pouvoir enregistrer toutes ces informations (trace de pile et informations de demande) dans un fichier sur mon serveur - pour que je puisse simplement les exporter sur ma console et voir les erreurs défiler, envoyez-moi le journal par courrier électronique. toutes les heures ou quelque chose comme ça.

Quelles solutions de journalisation recommanderiez-vous pour un site Django, qui répondraient à ces exigences simples? L’application fonctionne en tant que serveur fcgi et j’utilise un serveur Web Apache comme interface frontale (bien que l’on envisage d’aller dans lighttpd).

Answer 1

Eh bien, lorsque DEBUG = False , Django enverra automatiquement un suivi complet de toute erreur à chaque personne répertoriée dans le paramètre ADMINS , ce qui vous permet d'obtenir des notifications assez pour libre. Si vous souhaitez un contrôle plus fin, vous pouvez écrire et ajouter à vos paramètres une classe de middleware qui définit une méthode nommée process_exception () , qui aura accès à l'exception qui a été déclenchée:

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

Votre méthode process_exception () peut ensuite exécuter le type de journalisation souhaité: écriture sur la console, écriture dans un fichier, etc., etc.

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

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

Cela ne ne vous donne pas accès à l'objet exception, cependant, la méthode middleware est beaucoup plus facile à utiliser.

Answer 2

Django Sentry est un bon choix, comme cela a déjà été mentionné, mais il faut un peu de travail pour le configurer correctement (en tant que site Web séparé). Si vous souhaitez simplement tout enregistrer dans un fichier texte simple, voici la configuration de journalisation à mettre dans votre 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

Bien entendu, James a raison, mais si vous souhaitez enregistrer des exceptions dans un magasin de données, quelques solutions Open Source sont 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 de code la plus utile d'EMP. Je viens tout juste de le mettre en œuvre et, tout en essayant de trouver une option à la gestion, pour essayer de chasser un bogue, un avertissement de dépréciation indique que, avec ma version actuelle de Django (1.5.?), Un filtre require_debug_false est maintenant disponible. 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
        },
    },
}

Answer 6

Je viens d'avoir un problème avec mon script fcgi . C'était avant même que Django ait commencé. Le manque d’exploitation forestière est tellement douloureux. Quoi qu'il en soit, rediriger stderr vers un fichier comme la toute première chose a beaucoup aidé:

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