httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm MacCarthaigh <>
Subject Re: Forensic Logging
Date Tue, 30 Dec 2003 19:32:34 GMT
On Tue, Dec 30, 2003 at 06:52:07PM +0000, Ben Laurie wrote:
> >I realise that having the value of getpid() and time() to hand is useful
> >for forensic purposes, but a getpid():time():next_id++ will result in
> >duplicates accross even small clusters.
> Ah, I see :-) does mod_unique_id handle that?

It does indeed :)

> Well, the most obvious answer is to prepend a box id, which could either 
> be done when I generate the logs or when you collate them.

... which is getting more and more like the mod_unique_id approach,
which is why I think they may well be worth consolidating. Purely from
an avoiding replication point-of-view, but also from a tracability point
of view. Imagine a mod_[php|perl|script] is used to own a machine,
it would be super-useful if that scripts logs could correlated with
the forensic logs easily. 

So I might see an incomplete request in the forensic log, I can take
the forensic_id, and grep for it in my script logs and perhaps get more
details there. 

But I guess if you feel the special uuencode overhead is overkill for
a forensic_id (which is unlikely to ever have to be in a URL), then
o.k. - leave it out by default.

> >Though if mod_unique_id can be used if present that'll solve any
> >problems I'd have :)
> I can easily do that in 2.0 - I can call a "give me a unique ID" hook, 
> and if mod_unique ID is present, it can give me its. I could also do it 
> by making sure mod_unique_id is run first if present and fishing the ID 
> out of the environment, though that's a bit tacky.

The first option, and adding a new conversion specification for 
having the mod_unique_id id in a log string would definitely
be a solution that would scale well (think 20-node clusters
using syslog!). 

So I guess in summary;  1) No matter what, there should be some means of
the forensic ID being unique accross cluster nodes, which is trivial to do
:) 2) It'd be supercool to be able to log the unique_id for tracability.

> >Actually that reminds me, these days mod_unique_id's algorithim isn't
> >clever enough for some systems which use L4 switching or anycast
> >balancing, I have an experimental patch here somewhere which can help
> >fix that, must submit it.
> I'd advocate making the unique bit configurable, that must surely fix it 
> in all cases?

Yep, well excepting for the lousy-admin case, I'll dig out the patch
- I was using it to get around the IPv6 messiness a long time ago.

Colm MacCárthaigh                        Public Key:

View raw message