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





Reply via email to