On Fri, Jan 27, 2017 at 9:01 PM, Cyril Bonté <cyril.bo...@free.fr> wrote:
> Instead of using "unique-id-header" and temporary headers, you can use the
> "unique-id" fetch sample [1] :
>
> frontend public
> bind *:80
> unique-id-format %{+X}o\ %ci:%cp_%fi:%fp_%Ts_%rt:%pid
> default_backend ui
>
> backend ui
> http-request set-header X-Request-Id %[unique-id] unless {
> req.hdr(X-Request-Id) -m found }
Indeed this might be one version of ensuring that a `X-Request-Id`
exists, however it doesn't serve a second purpose (which I found most
important), namely of matching the HAProxy logs with the logs of a
downstream server (or an upstream client).
For example, suppose we have a client (an API library), which sets
`X-Request-Id` header to a random value, logs it, and makes the
request. This request reaches HAProxy, which because it uses a custom
`unique-id-format` which disregards the `X-Request-Id` header, will
log a completely different request id, but pass the "original" header
to the downstream server. The downstream server receives the request,
logs the request ID and gives back the response.
Now if we want to match all the three logs we can't. The client and
server logs are in sync, but the HAProxy logs uses its own custom
request ID.
By using the variant I proposed (setting the `unique-id-format` to the
actual value of the `X-Request-Id` header), we can match all the three
logs.
Ciprian.
P.S.: Obviously we can explicitly log the `X-Request-Id` header via a
capture, but it isn't as explicit (or easy to identify) as setting the
unique-id to the header value.
