Hi Roy,
On Tue, Dec 11, 2012 at 05:08:17PM -0500, Roy Smith wrote:
> Hmmm, yeah, this looks like exactly what my patch does. Cool.
Indeed, now I remember this old discussion where we were different ones
having different requirements. As I said at that time, we (Exceliance)
had plans for developing this. After we had redesigned the log format,
it was quite easy to extend the feature to define an HTTP header format.
That way anyone can define the format he needs. It is very possible
that some of the things you're currently doing are not possible with
the current format (I have no idea what), but you're really invited
to extend it if something is missing.
Now to respond your initial questions :
> >> I've just finished patching haproxy-1.5-dev14 to use my unique-id header
> >> code, which we discussed a year or so ago. There's one thing I'm not 100%
> >> sure about. You changed the interface of http_find_header2().
> >> Previously, the third argument was an int, now it's a char*. I'm assuming
> >> that where I used to do:
> >>
> >> + if (! http_find_header2(hdr, hdr_len, msg->sol,
> >> &txn->hdr_idx, &ctx)) {
> >>
> >> I now want
> >>
> >> + if (! http_find_header2(hdr, hdr_len, msg->chn->buf->p +
> >> msg->sol, &txn->hdr_idx, &ctx)) {
> >>
> >> yes? This is in proto_http.c, http_wait_for_request().
>From what I'm seeing, no, you just need msg->chn->buf->p, which is the
pointer to the beginning of current message in the request buffer. Please
have a look to doc/internal/buffer-ops.fig to get a better idea. The
"entities.fig" file in the same directory might also be of interest to you.
> >> Have you given any more thought to picking up this patch for the official
> >> version? We've been running it in production for well over a year with no
> >> problems. Yesterdays' traffic volume was 73 million HTTP requests, so I
> >> think we've given it a fair workout. The feature has proven invaluable
> >> for debugging problems in the site, as it lets us easily correlate lines
> >> in our haproxy, nginx, and application log files. I'm sure many other
> >> haproxy users would find it equally useful.
I'm totally convinced by the usefulness of such a feature. I've insisted
that we put this in our Aloha roadmap years ago because of this. But only
people who have previously used such a feature in production know its value.
Once you have this, you can completely rethink the log workflow, processing
and analysis. And the second best thing to have is perfectly synchronized
clocks on all your servers :-)
Best regards!
Willy
