[Web-SIG] again about logging in WSGI

[Graham Dumpleton]

On 24/11/2007, Manlio Perillo <manlio_perillo at libero.it> wrote:
> > As for everything else, as suggested in a previous email, you would be
> > better off basing anything else beyond sys.stderr and wsgi.errors off
> > the Python 'logging' module. In doing this, nothing would be required
> > in the WSGI environment. Any code would just log output using the
> > 'logging' module.
> >
>
> This is what I want to do.
> But instead of setup the 'logging' module in nginx mod_wsgi, I would
> like to offer a minimal support so that this can be done by the WSGI
> application (or middleware).
>
> In this way, the application is not forced to use the standard logging
> system.
> Moreover I do not want to make nginx mod_wsgi too "complex".
>
> > The magic missing bit would then be the WSGI adapter somehow making
> > available a type of LogHandler class, eg., ApacheLogHandler, which can
> > be referenced in configuration mechanism used to setup the 'logging'
> > module. As necessary the LogHandler can be tied into the WSGI adapter
> > dispatch mechanism so that it can know when something is logged in the
> > context of a request handler, as opposed to at global scope on module
> > import of WSGI application and correctly log details against the
> > internal request structure, thereby enabling of client IP details
> > against the request.
>
> Too complex, IMHO.

Actually, if you don't try and bind it back to a specific request, and
just use the main error log file, it is actually quite easy.

> I think that it is better to have two separate logging objects.
> wsgi.errors and sys.stderr, as an example.

Huh. These exist now. But you said you don't want to be using
sys.stderr since WSGI PEP says nothing about it.

> With these two objects a middleware/application can:
> - setup the global logging object using sys.stderr
> - setup(?) a logging object in the wsgi dictionary using wsgi.errors
>
> A first improvement is to add to the wsgi dictionary something like
> nginx.log_level (this must be done in the server configuration file,
> using, as an example, the `wsgi_param` directive)
>
> so that the middleware knows the log level used by the server.
>
> In this way, as an example, if the log level is 'NGX_ERROR' and a WSGI
> application do something like:
>    log.debug("a debug message")
>
> this message does not will be written to the server log.

I think I must be missing something about now nginx works. In Apache
the user code doesn't make the decision as to whether it needs to log
something or not. You log something, passing the notional log value
that the code wants that message to be logged at. Internally, Apache
will compare that notional log level to what it its threshold is and
decide to allow it through or not.

Thus, I don't understand why the log level threshold value which
dictates what is filtered needs to be exposed in the Python code side
of things.

I guess I'll just have to wait until later to see what it is you are
thinking of. :-)

Graham