Come si registrano gli errori del server sui siti Django

Così, quando si gioca con lo sviluppo posso solo impostare settings.DEBUGper Truee se un errore occures posso vederlo ben formattato, con la traccia buona stack e informazioni di richiesta.

Ma su un tipo di sito di produzione preferirei usare DEBUG=Falsee mostrare ai visitatori qualche pagina di errore standard 500 con informazioni che sto lavorando per correggere questo bug in questo momento;)
Allo stesso tempo, vorrei avere un modo per registrare tutto quelle informazioni (impila traccia e richiedi informazioni) a un file sul mio server - quindi posso semplicemente inviarlo alla mia console e guardare gli errori scorrere, inviarmi via email il registro 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 fcgiserver e sto usando apache web server come frontend (anche se sto pensando di andare su lighttpd).

Bene, quando DEBUG = False, Django invierà automaticamente una traccia completa di qualsiasi errore a ogni persona elencata ADMINSnell'impostazione, il che ti darà le notifiche praticamente gratis. Se desideri un controllo più accurato, puoi scrivere e aggiungere alle tue impostazioni una classe middleware che definisce un metodo denominato process_exception(), che avrà accesso all'eccezione sollevata:

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

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

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

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

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

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

django-db-log, menzionato in un'altra risposta, è stato sostituito con:

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

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.

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

Ho appena avuto un fastidioso problema con la mia fcgisceneggiatura. È 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')