Personally I have all logging categories configured to write to a single mailserver log file, and I find that it is pretty easy to trace a message from when it was received by the SMTP handler, through the matcher and mailer processing and on to its final destination, wherever that may be.
Steve > -----Original Message----- > From: Serge Knystautas [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 29, 2003 1:46 PM > To: James Developers List > Subject: Re: Message path tracing > > > Noel J. Bergman wrote: > > My first inclination is that Serge has the right idea, but possibly > > the wrong solution to the problem. Having per-message logs > (Msg#.log) > > won't scale, and I believe that problems arise other than > in someone's > > controlled test environment as they develop their pipeline logic. > > Good point. > > > It seems to me, and there is also a bugzilla entry that relates to > > this, that we should audit all of our message related log > formats to > > make sure that the content is parsable and has all of the necessary > > information to associate log messages with mail messages, and then > > provide a log analyzer. > > I may be forgetting, but I'm pretty sure this relates only to using > something like webalizer to analyze sendmail-style logs, so > as I put it, > the SMTP-stuff. > > > A hypothetical pipeline analyzer could merge the various existing > > logs, sort them by message key, and then filter out events by the > > message(s) we're interested in following. > > While this could help isolate an odd production bug, I think it fails > for users trying to learn James and actively debug mailets or > matchers. > > > Serge has made a point that logs for smtp traffic analysis and logs > > for pipeline debugging might have different > content/formats. Possibly > > so, but I don't believe that precludes using a log analyzer. > > I understand a log analyzer for smtp traffic (like > webalizer). Unless > you're talking about some GUI analysis of some after-the-fact logging > (which I don't even like that much), I don't see much value. > Sure, it's > better than what we have, but that says little. > > > Either way, we have to go through SMTP handler, the pipeline, into > > matchers and mailets (at least in my opinion), and the POP3 > handler, > > and make some logging changes. At the minimum, it would seem to me > > that want to log > > This mailet & matcher log changes... I was just talking of adding the > message info in the logs. Adding message info in the logs is doable > without touching the implementations, and in all but lifecycle > situations, the log messages have a message associated with them and > could in most cases benefit from that info. > > This is an important point to me because it determines whether we add > code in 3 places, or 18 + every custom mailet & matcher people use. > > > I believe that Serge's idea is that we would instrument the SMTP > > handler (probably also any similar message source, such as > FetchMail), > > the spooler, and the log operation(s) in the MailetContext. > We would > > have some redundant logging code, but hopefully could keep it to a > > minimum. I'm not sure how this per-message log would tie into the > > Avalon code, but that's TBD if we go this route. > > I don't see how Avalon code relates to what we're talking > about. What > code is redundant? > > > Personally, I prefer the log analyzer approach for a few reasons: > > > > - logs for the log analyzer could be left on with > > some degree of verbosity > What's the benefit or objective? We already have debug/info/etc... > control over level of verbosity, but it's still very > difficult to track > and goes beyond sending messages to different streams. > > > - the per-message log mechanism would rapidly create > > too many directory entries for many platforms. > Yes, it's not scalable, which is the one outstanding issue. > > > - no redundant code > What is redundant? You seem to be critiquing the way you would > implement this... > > > - resolves bugzilla > This is unrelated, IMHO. > > -- > Serge Knystautas > President > Lokitech >> software . strategy . design >> > http://www.lokitech.com p. 301.656.5501 e. > [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
