james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Short" <ssh...@postx.com>
Subject RE: Message path tracing
Date Tue, 29 Jul 2003 21:03:22 GMT

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:sergek@lokitech.com] 
> 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. 
> sergek@lokitech.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message