Hello,
I'm currently looking into possibilities to improve regular logging
output for DSPAM. Currently, DSPAM does not log anything when running
normally. There is no easy way to see regular activity within a DSPAM
process. There are ways around this such as enabling TrackSources which
logs 1 line for each processed message (under most circumstances), but
this is far from ideal.
The idea is to make DSPAM output some informal logging about its own
activity. To do this, my general idea is like this:
- Add LOG(LOG_INFO, "informal message") to applicable places in the code
- Add the actual strings to language.h in the same way current logging
(90% errors) is done.
- Convert some of the existing debug messages to LOG(LOG_DEBUG...
statements and enable them even when --debug is disabled
- Add a directive to dspam.conf that enables the user to change
verbosity: LogLevel {debug,info,notice,warn,critical,alert,emerg} and
log all messages above and including this level to the regular logging
channel (syslog or ./configure --with-logfile=<path>)
The general logging output should pass the following requirements:
- Each (interesting) event should ad one (and only one) line to the log
- A log entry should be short but informative, and contain as much
relevant information as possible.
- LogLevel set to "info" should result in output that enables an
administrator (i.e. no developer) to see high level message handling on
a per-message basis.
- LogLevel set above "info" should only output issues, as is currently
done (albeit because no messages of level "info" or "lower" are
available in the code).
- LogLevel set to "debug" should add output that helps administrators to
find configuration issues.
- Output that is only helpful for developers or significantly impacts
performance (because extra calculations/queries/etc are needed) should
be logged only when
--enable-debug/--enable-bnr-debug/--enable-verbose-debug options are
enabled at compile time. This is currently already being done.
Other things to consider:
We could write all the debug output to the regular logging channel,
thereby eliminating the current (IMHO annoying) practice of logging to
different files.
Current error messages can be enhanced when possible. Depends on the
case, but adding debug/warning messages deeper inside the code should
reveal more information when someone is interested.
If needed we could add some unique identifier for each message passing
though DSPAM, so log lines for each messages can be grouped together
easily (MTA queue id alike).
Example
-------
We are running dspam as daemon and a message is processed. Loglevel is
set to "info". This means that a line is logged for each of the events:
- external entity connects to dspam via LMTP or dspamc
- dspam classifies message, and decides what the result is
- dspam handles message according to result (quarantine/send over smtp/etc/)
Thus, normal execution of a message results in 3 log lines. This seems
reasonable to be, since other applications (f.i. postfix) are able to
produce much more logging without harming performance.
As I'm sure I'm not the only person that is annoyed by the lack of
regular processing output in DSPAM, I'd like to hear your ideas and
comments on the above.
--
Tom
------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Dspam-devel mailing list
Dspam-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspam-devel
