Michael Holzt wrote:
In response to Matts suggestion of doing the logging in a deny hook, i just
created a 'denylog' plugin, which can be configured for which plugins a deny
should be logged and with which loglevel.
I like this in theory, but in practice I'd like to see something more general (and something which doesn't require modifying plugins).
I've been mulling in my head something I'd like to call "adaptive logging" for lack of a better term. For example, I am strangely disinterested in logging lots of information for sucessful transactions. I barely want FROM:/TO: on stuff I accept. Yet, the more details I can get for certain denials, the easier it is to debug problems. I don't want to see anything for viruses I block apart from the name (I don't even need to see FROM:/TO: because, who cares). If I block something based on a blacklist, I want to see full details so I can track if I need to add the host to our internal whitelist. I'm sick of ratcheting up the loglevel and testing something then turning it back down.
So, what I was thinking was taking the 'denylog' idea to it's natural conclusion and wrap _all_ logging operations. Then any logging that would normally be emitted by a plugin would be held until the last moment, when the determination would be made over what to write out:
1) If a plugin exited with OK, only display those lines below the log_level;
2) If a plugin exited with a DENY, display those lines below the log_threshold (what Michael calls 'denylog_level');
3) Other exit values would be mapped to either one or the other above behaviors, or even ignored completely (like I don't necessarily need to see anything from a plugin that exits DECLINED);
4) Allow a plugin to specifically decline to participate in this procedure (in which case log entries just passes through this and remains consistent with current behavior).
It would seem like one way to handle this is through a DESTRUCT method on the transaction and connection objects, which would step through the array of stored log entries and emit the ones which fit the criteria chosen. This would have the effect of condensing all lines for a given transaction into close proximity in the log output at the expense of some additional storage for the object.
I haven't gotten any farther than thinking about this in the shower, but I thought I'd throw it out for comments...
John
