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: [EMAIL PROTECTED]
