Come si registrano gli errori del server sui siti Django

Question

Quindi, giocando con lo sviluppo, posso semplicemente impostare settings.DEBUG su True e se si verifica un errore posso vederlo ben formattato, con una buona traccia dello stack e richiedi informazioni.

Ma su un tipo di sito di produzione preferirei usare DEBUG = False e mostrare ai visitatori qualche pagina di errore standard 500 con informazioni su cui sto lavorando per correggere questo bug in questo momento;)
Allo stesso tempo, vorrei avere un modo per registrare tutte quelle informazioni (impilare traccia e richiedere informazioni) su un file sul mio server - quindi posso semplicemente inviarlo alla mia console e guardare gli errori scorrere, inviare via email il registro a me ogni ora o qualcosa del genere.

Quali soluzioni di registrazione consiglieresti per un sito django, che soddisferebbe quei semplici requisiti? Ho l'applicazione in esecuzione come server fcgi e sto usando il web server apache come frontend (anche se sto pensando di andare su lighttpd).

Answer 1

Bene, quando DEBUG = False , Django invierà automaticamente un traceback completo di qualsiasi errore a ogni persona elencata nell'impostazione ADMINS , che ti farà ricevere notifiche per gratuito. Se desideri un controllo più accurato, puoi scrivere e aggiungere alle tue impostazioni una classe middleware che definisce un metodo chiamato process_exception () , che avrà accesso all'eccezione sollevata:

http://docs.djangoproject.com/en / dev / argomenti / http / middleware / # processo-eccezione

Il tuo metodo process_exception () può quindi eseguire qualsiasi tipo di registrazione tu voglia: scrivere sulla console, scrivere su un file, ecc. ecc.

Modifica: sebbene sia un po 'meno utile, puoi anche ascoltare il segnale got_request_exception , che verrà inviato ogni volta che si verifica un'eccezione durante l'elaborazione della richiesta:

http://docs.djangoproject.com/en / dev / ref / segnali / # got-richiesta-eccezione

Questo non ti dà accesso all'oggetto eccezione, tuttavia, quindi il metodo middleware è molto più facile da lavorare.

Answer 2

Django Sentry è una buona strada da percorrere, come già accennato, ma è necessario un po 'di lavoro per configurarlo correttamente (come sito Web separato). Se vuoi semplicemente registrare tutto in un semplice file di testo, ecco la configurazione di registrazione da inserire nel tuo 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, menzionato in un'altra risposta, è stato sostituito con:

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

Answer 4

Ovviamente James ha ragione, ma se si desidera registrare le eccezioni in un archivio dati, sono già disponibili alcune soluzioni open source:

1) CrashLog è una buona scelta: http://code.google.com/ p / django-crashlog /

2) Db-Log è anche una buona scelta: http: // code.google.com/p/django-db-log/

Qual è la differenza tra i due? Quasi nulla che io possa vedere, quindi uno dei due sarà sufficiente.

Ho usato entrambi e funzionano bene.

Answer 5

È passato del tempo dall'invio del codice più utile di EMP. L'ho implementato proprio ora, e mentre mi lanciavo con qualche opzione manage.py, per cercare di inseguire un bug, ho ricevuto un avviso di deprecazione secondo cui con la mia attuale versione di Django (1.5.?) È ora disponibile un filtro request_debug_false necessario per il gestore mail_admins.

Ecco il codice rivisto:

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

Ho appena avuto un fastidioso problema con il mio script fcgi . È successo prima ancora che django iniziasse. La mancanza di registrazione è così dolorosa. Ad ogni modo, il reindirizzamento di stderr a un file come prima cosa ha aiutato molto:

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