My Goals 1. logs that are easy for humans to observe and parse
2. logs entries that have a consistent syntax. This would enable us to write log processors that could accurately summarize the logs and spit out statistics for apps like munin, rrdtool, nagios, et al. Regardless of which logging plugin(s) are in use. The most important thing for accurate log processing is a consistent disposition keyword. For example, if a plugin might reject connections or messages, then it should include the keyword reject or accept. Or pass+fail. Or allow+deny. I would like us to pick a set of keywords and then I'll modify every plugin to conform. Before Example: 27804 spamassassin (data_post): pass, -0.5 < 100 27804 dspam (data_post): Innocent, probability=0.0000, confidence=0.99 27804 virus::clamdscan (data_post): ClamAV scan reports clean After Example: 27804 spamassassin (data_post): pass, -0.5 < 100 27804 dspam (data_post): pass, Innocent, probability=0.0000, confidence=0.99 27804 virus::clamdscan (data_post), pass: clamav reports clean The consistent keyword in there is pass. The special keywords should never be logged more than one time per connection. I don't really care which keywords are used. Just so long as every plugin uses them in the same way. Then a user can have the spamassassin plugin spraying 10 lines of debug info in the logs and it won't affect the counters. Log messages can be altered and nothing breaks, so long as the keywords remain. While we're at it, doesn't this minor change improve human readability? 27804 (data_post) spamassassin: pass, -0.5 < 100 27804 (data_post) dspam: pass, Innocent, probability=0.0000, confidence=0.99 27804 (data_post) virus::clamdscan : pass: clamav reports clean I just moved the hook name in front of the plugin. The hook names are often grouped in the logs, and they tend to have a more consistent length than the plugin name. 3. the ability to increase/decrease loglevel for individual plugins. It would be quite handy to append an argument like this to the end of a plugin that I want to debug: loglevel +1. Or to quiet a particularly chatty plugin: loglevel -1. Behind the scenes, those config options would be detected and every time that plugin called log->(LOGINFO, ...), it would get logged as if it were LOGDEBUG or LOGNOTICE. This would give users a ton of control over logging. And it could happen without making any changes to the plugins. 4. If the plugin alters the connection in any way, the change is logged. (most plugins already conform) 5. Under normal circumstances, at LOGINFO, each plugin should log a single entry. I'm very open to thoughts and concerns. Matt
