[Web-SIG] again about logging in WSGI

[Manlio Perillo]

Graham Dumpleton ha scritto:
> [...]
>> 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.
> 

No, sys.stderr is fine.

>> 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.
> 

It is the same with Nginx.

> 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 have posted an example.

Let's suppose that the log levels in the server are:
NGX_LOG_EMERG             1
NGX_LOG_ALERT             2
NGX_LOG_CRIT              3
NGX_LOG_ERR               4
NGX_LOG_WARN              5
NGX_LOG_NOTICE            6
NGX_LOG_INFO              7
NGX_LOG_DEBUG             8



Now let's suppose that the wsgi.errors and sys.stderr internally use the 
NGX_LOG_ERR log level (but this should be modificable by the user, IMHO).


Finally, the WSGI application calls:
log.debug("ops").


The problem with this is that, in the log file, it could be added:
2007/11/24 11:46:09 [err] 29902#0: *1 DEBUG ops


This is not what I want.
A message with DEBUG log level should not be written to the log file.


The solution is to do:
{
   # nginx config file
   ...
   wsgi_param  nginx.log_level  40 # logging.ERROR
   ...
}

logging.basicConfig(level=environ['nginx.log_level'],
     format=%(levelname)s %(message)s', stream=sys.stderr)



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



Manlio Perillo