zain / jogging

Easier Django logging!
MIT License
103 stars 5 forks source link

WSGI problems #7

Open nopper opened 14 years ago

nopper commented 14 years ago

I'm running a django web application by using fcgi (SCGI protocol) as backend. What I get is a plenty of useless log messages coming from scgi-wsgi logger, after each HTTP GET request. I wasn't able to disable this logger, neither with the use the NullHandler(). Currently my configurations is something like that:

from jogging.handlers import DatabaseHandler, NullHandler
import logging

GLOBAL_LOG_LEVEL = logging.WARN
GLOBAL_LOG_HANDLERS = [DatabaseHandler()]

LOGGING = {
    'scgi-wsgi': {
        'handlers': [NullHandler()],
        'level': logging.INFO,
    }
}

Of course, this configuration seems not to solve the situation. The content of these log messages is pretty useless, as I already said. This is an example:

mysql> SELECT id, datetime, level, msg FROM jogging_log WHERE source='scgi-wsgi' LIMIT 3;
+-----+---------------------+-------+---------+
| id  | datetime            | level | msg     |
+-----+---------------------+-------+---------+
| 182 | 2010-06-20 02:26:52 | INFO  | %s %s%s |
| 183 | 2010-06-20 02:26:57 | INFO  | %s %s%s |
| 180 | 2010-06-20 02:23:06 | INFO  | %s %s%s |
+-----+---------------------+-------+---------+
3 rows in set (0.00 sec)
zain commented 14 years ago

This might be caused by Issue 5 which was fixed in cbc2721. Try upgrading to HEAD to see if your issue is fixed.

nopper commented 14 years ago

Nope. I'm using the latest revision.

Torkn commented 14 years ago

I encountered a similar problem with the database filling up despite setting level to a higher level, and fixed it here:

http://github.com/Torkn/jogging/commit/d88cde120ecb9de4ca4a3bc5786baaa11241ce5c

I added a get_level(self, source) method to LoggingWrapper to handle the issue of determining the appropriate logging level in a consistent manner.

You might like to check out my entire branch: http://github.com/Torkn/jogging/tree/

It adds functionality to allow you to see the latest log message from any given source, without accumulating thousands of logs. Selectable from the admin. Great for logging of status messages.

nopper commented 14 years ago

Thanks for your comment! I've tried your branch but the problem is still there. Maybe the issue is due to a misconfiguration?

ianlewis commented 14 years ago

I never really liked this module logging stuff. Some of Torkn's changes could be incorporated into jogging but I'm not sure that I would like to incorporate all his changes. It doesn't really look like it solves this issue anyway.

mod-wsgi might be doing something strange here. Can you reproduce this bug locally if with the same configuration as above you say, get the logger for 'scgi-wsgi' and log to it?

Torkn commented 14 years ago

It appears that my current fork does not solve this particular problem. I encountered a very similar problem (DB log being written despite log level being too low) and fixed that for calls made via jogging, but this is different. In this case, the module is unaware of jogging and is just using the python logger directly. It seems the handler still gets called even though the log level should have prevented it.

I added an explicit check in handlers.py class DatabaseHandler for the record.level >= handler.level. But this should not be needed, since the logging module should have already checked this. Perhaps the logging.Handler.level is not being set as expected.