On Jan 26, 2011, at 1:09 AM, Willy Tarreau wrote: > Hi Roy, > > On Sun, Jan 23, 2011 at 10:04:57AM -0500, Roy Smith wrote: >> Cool. What can I do to help? > > Could you try to identify precisely how it would be used at your site ? > Try to think about these cases : > - what to do with reqids that are already present in requests
I don't see how that would happen. Maybe if we did something like stack one haproxy behind another, but I don't see any reason we would do that. But, if it were to happen somehow, I think we would just leave it untouched (and log that we saw it). The goal is to have a unique identifier so that every process that's involved in responding to a request can log the id, allowing us to correlate logs. If the incoming request already has such an id, there's no reason to change it. > - what to do with reqids in responses > => compare them with the request's, block if they do not match > => delete them or not depending on where you're responding I'm not sure I understand what you're asking. > - what to log > => do we always need to log a full reqid or can we sometimes just > log one part of it What do you mean by logging "one part" of an ID? The ID is just a unique tag. I don't understand how it can be divided into parts. > - what info to include in it. For what I want, the only information it needs to have is a unique tag so we can trace a request through the system. I would think a constant string defined in the config file plus a counter would be sufficient. > One of my customers has designed one years > ago and has been asking for its integration into haproxy. Lack of time > and priorities, etc... It basically includes src ip+port, dest ip+port, > instance name, timestamp, pid and counter. I could see how people might want all that stuff, but for my use, just the counter would be sufficient. > I identified that it had to > be extended to support IPv6 and possibly more than 64k req/s/instance. > Overall I'm fine with it because it has permitted to trace requests > through a long chain for years. But maybe you have different needs that > should be studied before something is implemented. For instance, it's > possible that some users might prefer to hash it so that info present > in it cannot be reversed when passing it to external service providers. Again, I could see why people might have those concerns, but for my use, just a simple counter is fine. All I need is a unique tag attached to every incoming request. -- Roy Smith r...@panix.com
