add http.request.id

[graphaelli]

It is very common for web servers to generate a unique id for all incoming requests. For example, heroku standardizes this in X-Request-ID. Elastic APM Server itself has assigned unique request ids since v6.2.

This information is useful for analyzing per-request logs.

[ebeahan]

Should we also consider a response field, http.response.id?

This does touch on a long-outstanding issue of how to best handle capturing HTTP headers in ECS (#232). ECS will eventually have better guidance on where to capture arbitrary HTTP headers, including non-standard X-prefixed headers. Regardless of how that guidance shapes up, certain headers will still be valuable captured in their individual fields.

In this case, the unique identifier could appear across multiple header names depending on the underlying app, service, or framework implementation (X-Request-ID, X-Correlation-ID, etc.). So I think normalising to http.[request|response].id is reasonable here.

[graphaelli]

I don't have a need for http.response.id but up for doing the legwork if that would help move http.request.id along.

[ebeahan]

Thanks, @graphaelli, for expanding the description! The extra context will help direct users on what sort of identifiers can be used to populate the field, I think.

Let's focus solely on http.request.id for now.

Everything here LGTM 👍