Hi Simon,
Simon Willison wrote:
> 1. We'll be able to de-emphasise the current default "e-mail all
> errors to someone" behaviour, which doesn't scale at all well.
In a recent thread[1] on a similar topic Russel has also emphasized that
we should improve documentation about doing logging.
> 3. Logging in Django core rather than a 3rd party app will encourage
> reusable applications to log things in a predictable way, standard
> way.
Talking about predictable and standard way I want to be sure that we
don't break existing logging.
I.e. we at Yandex now have many reusable Django apps that don't setup
loggers themselves but just log things into named loggers and expect
them to be setup by a project that uses them.
What I gather from your proposal is that you want the same model ("an
app logs, a project setups") plus a nice declarative syntax in
settings.py instead of boring creation of handlers, formatters and
loggers. Right?
> - We could replace (or complement) django.connection.queries with a
> log of executed SQL. This would make the answer to the common question
> "how do I see what SQL is being executed" much more obvious.
In the thread that I was referring to[1] we kind of agreed on using a
signal there. Then hooking a logger onto the signal is simple.
> 5. People might leave logging on, then find their server disk has
> filled up with log files and caused their site to crash.
We had this problem with standard logging. Then we switched to a
RotatingFileHandler which wasn't very good however because its behavior
is simplistic and is not controllable by admins with an interface that
they know, namely logrotate. Setting up logrotate also wasn't without
problems. When it rotates a file it should let an app know about it and
it uses SIG_HUP for that. However this instantly terminates Django's
flup-based FastCGI server which we use.
Now we've settled on a WatchedFileHandler ported from Python 2.6 logging
module. It watches for file descriptor change and doesn't require
SIG_HUP to pick up a new file. May be we should port it to Django and
use it as a default handler for logging to file system.
> 6. Logging levels are confusing - what exactly is the difference
> between warn, info, error, debug, critical and fatal? We would need to
> document this and make decisions on which ones get used for what
> within the framework.
May be we can just leave it for users to decide. It depends so much on
how much an app actually wants from logging.
The only standard thing I can think of is to have DEBUG = True imply
level = logging.DEBUG (which includes everything more sever). DEBUG =
False will imply logging.INFO then. What do you think?
> # If you want custom log handlers - not sure how these would interact
> with
> # channels and log levels yet
> LOG_HANDLERS = (
> 'django.core.log.handlers.LogToDatabase',
> 'django.core.log.handlers.LogToEmail',
> )
This is a hard problem really. Most handlers require different set of
arguments. File names, email credentials, system idents for SysLog etc.
Also there should be different formatters. For example there's no point
to waste space in a syslog message on a timestamp since syslog tracks it
itself...
[1]:
http://groups.google.com/group/django-developers/browse_frm/thread/9d0992e800cf7d68#
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
