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
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
