Django logging in Satchmo

[hynekcer]

Hi all,
you know that Satchmo has by default logging to the file satchmo.log,
which is ferfect for development but not so for production.

WHAT USE YOU?

It is well known that with multiprocess deployment can be parts of the
log overwritten by other processes. [1] The conclusion there is "(any
recommendation) requires building consensus on the Django Developers
mailing list."

A problem is if we ask here for any not easy reproducible problem:
"Have you seen any (bla bla) message in the log?" and the answer is
"No one." The most people probably did not changed logging and only
added File Rotating. Has not been the only existing such message
overwritten?

I personally use an imperfect very simple short solution. (adding
process number to the filename - which should not be recommended)
There should be other solutions. I googled something [2] [3] but I am
not prepared to recommend anything to all.

[1] https://code.djangoproject.com/ticket/14625
[2] http://readthedocs.org/docs/django-logstream/
[3] http://fairviewcomputing.com/blog/2008/03/05/django-request-logging/

[Chris Moffitt]

I would be interested as well to hear how Satchmo logging is used in different setups. To be honest, I haven't played with it recently but it does seem like the current logging is so verbose it's tough to use I haven't played around enough to figure out a right answer but would appreciate hearing what others are doing.

-Chris

--
You received this message because you are subscribed to the Google Groups "Satchmo users" group.
To post to this group, send email to satchm...@googlegroups.com.
To unsubscribe from this group, send email to satchmo-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=en.

[hynekcer]

Chris,
I restrict now strong logging of database queries, which is anoying
with Django 1.3 for DEBUG log level, by adding a line to my
local_settings.py

logging.basicConfig(level=logging.DEBUG,... )
+logging.getLogger('django.db.backends').setLevel(logging.INFO)
logging.getLogger('keyedcache').setLevel(logging.INFO)

For new installations I wrote a patch.

[Mike Johnson]

Hi Chris,

This is how I've got logging setup in 1.3. I'm keeping it as simple as possible and printing everything to the "console," which is picked up by the web server and written out to the error log. That's easier to use than Python logging because the webserver takes care of rotation and thread race issues for me.

The only manual setting I have is for keyedcache, which can be quite verbose at the INFO level.

Thanks!
Mike

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'verbose': {
            'format': '%(levelname)s %(asctime)s %(module)s %(process)d %(thread)d %(message)s'
        },
    },
    'handlers': {
        'console':{
            'level': 'DEBUG',
            'class': 'logging.StreamHandler',
            'formatter': 'verbose'
        },
        'mail_admins': {
            'level': 'ERROR',
            'class': 'django.utils.log.AdminEmailHandler',
            'include_html': True,
        }
    },
    'loggers': {
        'django.request': {
            'handlers': ['mail_admins'],
            'level': 'ERROR',
            'propagate': True,
        },
        'keyedcache': {
            'handlers': ['console'],
            'level': 'ERROR',
            'propagate': False,
            },
        '': { # everything
            'handlers': ['console'],
            'level': 'INFO',
            'propagate': True,
        },
    }
}

[hynekcer]

Does anybody noticed missed log messages with existing logging
solution for some multiprocess server configuration? (I ask again for
sure)

Thanks Mike,
you are right it is good to write at least ERROR or maybe warning
level to webserver log to be sure that nothing important never
disappears and all errors are together.
The existing solution with external file which is rewritten on every
django restart is however very good for debugging.

It reminds me that it is good to use settings.py derived more from the
default settings.py of different new Django versions. That means that
we should provide at least one additional template different for
Django 1.2 and Django 1.3. Now I am preparig only minimal differences
which are requested by Django warnings and which can be done by simple
string substitution.

-- Hynek