Opened 20 months ago

Closed 6 months ago

Last modified 6 months ago

#19395 closed Cleanup/optimization (fixed)

Improve logging section by providing a SIMPLE example

Reported by: ken.nelson@… Owned by: nobody
Component: Documentation Version: 1.4
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no



New to Python and Django. We have been gifted with several Django sites to maintain. These sites are poorly written and have no debug capabilities, so i wanted to enable a primitive log to report on uncaught exceptions, as well as a place we can manually write to. I don't have all afternoon to work through all the permutations of Python logging; I just need the most basic. So, the fact that the only log config example you provided is humungous is disappointing.

I'm sure many would be grateful for a minimal single textfile logging example they can just cut'n'paste and use ASAP. Thanks.

Attachments (1)

19395.diff (1.6 KB) - added by timo 6 months ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 20 months ago by anonymous

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

I heard some people being very enthousiastic about logbook: . Though that doesn't solve the docs, it might be worthwile to take a look on their website. They give an example right-away, and it is very clear.

comment:2 Changed 20 months ago by aaugustin

  • Triage Stage changed from Unreviewed to Accepted

comment:3 Changed 20 months ago by ken.nelson@…

Thanks to commenter for the suggestion re logbook ( ). Our main requirement is for something to catch and report on _untrapped_ errors, so the built-in Python/Django logging is required.

comment:4 Changed 20 months ago by jkeyes

I think it's unclear what a simple example would be. Logging to syslog, to stdout, ...?

The following is the logging code in generated by ( startproject ...):

# A sample logging configuration. The only tangible logging
# performed by this configuration is to send an email to
# the site admins on every HTTP 500 error when DEBUG=False.
# See for
# more details on how to customize your logging configuration.
    'version': 1,
    'disable_existing_loggers': False,
    'filters': {
        'require_debug_false': {
            '()': 'django.utils.log.RequireDebugFalse'
    'handlers': {
        'mail_admins': {
            'level': 'ERROR',
            'filters': ['require_debug_false'],
            'class': 'django.utils.log.AdminEmailHandler'
    'loggers': {
        'django.request': {
            'handlers': ['mail_admins'],
            'level': 'ERROR',
            'propagate': True,

Is this a simple enough configuration to begin with?

Aside: For unhandled exception tracking, I think you should have a look at Sentry or Exceptional.

comment:5 Changed 19 months ago by ken.nelson@…

Thanks! Email notification would be a good starting point, especially for a live site. Me, I've always preferred a simple text log, especially at the development stage. I can't understand how people can develop without one, frankly, but that's just my opinion.

Here's what I ended up with, after spending some time in the Django docs:

    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
            'level': 'DEBUG',
            'class': 'logging.FileHandler',
            'filename': '/var/log/django/cotizador.log',
    'loggers': {
        'django.request': {
            'handlers': ['file'],
            'level': 'DEBUG',
            'propagate': True,

It seems to work, and is catching untrapped exceptions, but I'm sure it could be improved. The first things I'd add are the formatter with timestamp, and nightly file rollover.

I think that an example containing both the emailer instance and a simple textfile instance would help 99% of users get something working right away. Again, thanks.

Changed 6 months ago by timo

comment:6 Changed 6 months ago by timo

  • Has patch set

comment:7 Changed 6 months ago by claudep

I don't think that which writes all logging to a local file is true. all request logging would be probably more correct.

comment:8 Changed 6 months ago by Tim Graham <timograham@…>

  • Resolution set to fixed
  • Status changed from new to closed

In 69f0249d7b6dfbf278bbc2d5907f598d5ed241af:

Fixed #19395 -- Added a simple example logging config.

Thanks ken.nelson at

comment:9 Changed 6 months ago by Tim Graham <timograham@…>

In a05ca51c08d1cc4e69ca9b33a5a519e062d8236f:

[1.6.x] Fixed #19395 -- Added a simple example logging config.

Thanks ken.nelson at

Backport of 69f0249d7b from master

Add Comment

Modify Ticket

Change Properties
<Author field>
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.