On 24.08.2011 21:27, Tom Hendrikx wrote:
> Hello,
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
this will result in bigger binaries and more memory needed to run DSPAM.
Currently DSPAM does not compile some code if --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.
What different files? Do you mean the SQL logging and the message
content logging?
> 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).
Currently DSPAM does not have such code/id because it does not have a
queue management.
> 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.
Without harming performance? No way! Each logging is by definition
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.
I am not against additional logging. The question that I have is: Why
the additional logging? What is the purpose of it? What goal do you try
to reach with more logging?
> --
> Tom
Steve
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
