logging proposal

[Eric Moritz]

This proposal describes a possible way that logging will work inside
of Penny Press.

Application logging configuration:

Penny Press applications simply use the Python logging module. You
must use the module name
that the logger is currently used in.

For instance for the pennypress.apps.news application, in the
templatetags module. You should invoke the logger as so:

logger = logging.getLogger("pennypress.apps.news.templatetags")

This properly utilizes the hierarchal nature of the Python logging
module so that sites can configure logging handlers for
"pennypress.apps.news" , "pennypress.apps", etc that will allow the
configuration the trickle down to the child loggers.

For instance for a specific template tag in the pennypress.apps.news
application you can create a logger called,
"pennypress.apps.news.templatetags.GetStoryListNode that will inherit
the settings defined by an application for the pennypress.apps.news
logger or simply the pennypress logger.


Site logging configuration:

For each Penny Press site there should be a loggers.py module that
will configure the loggers for the site. This should be imported by
the site's settings.py module.

For different role settings you should do the following in your
roles.production.settings module:

from roles.production import loggers

This will allow you to configure loggers differently for the
production environment.

[Eric Moritz]

This proposal doesn't force any penny press user to follow the
logging convention. This is really the K.I.S.S. description of a
solution. We could automate the loggers.py loading by Penny Press,
but I don't know if that is a good solution.

Eric.

[Glenn Franxman]

Makes sense to me. I like the organization for the settings, etc too.

[Michael]

This sounds good to me and I like the simplicity of it all as well as the pythonic nature. I have two things that we should consider.

One: Django-logging[1] allows an external interface, which is created through middleware to show the logging calls and also some other Django and database information that is very useful. I find this type of interface and a few other features that Django-logging provides to be very useful while developing and wouldn't mind even using that application in Penny Press. The syntax is pretty much the same as proposed.

[1] http://code.google.com/p/django-logging/

Two: I have found that I like my logs better than just the e-mails that Django sends when a server error is encountered. Currently I override the WSGIhandler in django.core.handlers.wsgi and when a error occurs instead of e-mailing it does a critical error in the logs. This allows me to view my logs in context with a server error and handle those errors in a better way (I ended up with about 100,000 emails when a database died which required this necessity). I don't know if it is in the scope, but it might be interesting to subclass a few handlers to use the penny press logging instead of the django errors.

Anyway I am all for a logging plan. Simplicity is always good. Just thought I would bring up our current tools when we log our sites. Thanks, Mn

[Eric Moritz]

Yeah, I've looked at django-logging before. I think I'll leave that
up to the developer using Penny Press to turn on if they want.

For error handling: Yeah I'm definitely going to look into adding
logging to Django core.
It may take some monkey patching to accomplish universally. We'll
have to see.

At the moment the best thing is proper use of the logger module inside
of apps, the rest will follow.


On Feb 3, 11:30 am, Michael <newmani...@gmail.com> wrote:

> On Mon, Feb 2, 2009 at 2:01 PM, Glenn Franxman <gfranx...@gmail.com> wrote:
>
> > Makes sense to me.    I like the organization for the settings, etc too.
>