Introduce size metrics for HTTP.

[webmat]

This PR introduces the concept of metrics for HTTP events. It currently adds only the metrics for body and total (which includes headers). It's missing the obvious third wheel, header sizes. I wouldn't mind adding them if people feel strongly about it, but I haven't seen it come up in the few web server logging directives I've reviewed.

Speaking of which, here are some equivalencies:

• http.request.bytes.total: Apache httpd's %I, NGINX $request_length
• http.request.bytes.body: content-length header, NGINX $content_length, Traefik RequestContentSize
• http.response.bytes.total: Apache httpd's %O, NGINX $bytes_sent
• http.response.bytes.body: Apache httpd's %B, NGINX $body_bytes_sent, Traefik DownstreamContentSize (I think)

I do think logging both makes sense, for people who want detailed metrics.

In recent ECS migrations of Beats modules, I've seen a few modules using a content_length field. So there's a need for the metrics. However I feel like the term "content_length" comes with a bit too much meaning to start from there and define the other fields.

I'm open to discussing other ways of naming the fields. We could use "size" instead of bytes, or not nest so much (e.g. .size, .body_size and if we go there, .header_size).

• Note that this PR is built on top of Re-introduce http precisely as it was, as of #d8cece6 #237. It shouldn't be merged before it.

[webmat]

I'm flagging this for beta2. I'd like it to get in there, but I don't think it's the end of the world if it doesn't.

[ruflin]

We have above response.bodywhich contains the content of the body and here we have the size of it. What about response.body.content and response.body.size?

[webmat]

I like the grouping this enables: .header.bytes, .body.bytes. Which eventually leaves room for other metadata, if we ever want to track .body.encoding & such.

However do we use http.[request|response].body anywhere? Would moving that to .body.content be another "concrete field" => object transition, like source?

[ruflin]

It would also allow adding something like body.hash if the body should be compared but not the full body stored.

We use http.request.body today in Metricbeat in the http module. So an alias would not be possible but I think it's fine in this case as it is with source.

[webmat]

Ok, I could have sworn we had added http.request.body already, but we haven't. If we go forward with this PR, we need to make sure to revisit it if http.request.body goes in (#263).

[ruflin]

This will need a changelog entry (or multiple).

[webmat]

As discussed elsewhere, I will incorporate the changes from #263 into this PR and introduce all of this in one go.

[webmat]

@ruflin As discussed, the addition of the body field is now in this PR. I've also added changelog entries for everything that's happening. I'm nesting them all under the "Reintroducing http" entry. Since http was not part of beta 1, I would say that the body => body.content rename is not an ECS breaking change. WDYT?

@MikePaquette Can you check out this PR? I'd love it if we were able to get this into Beta 2. This adds fields for HTTP size metrics. Total size and body size for both request and response. As discussed earlier, this structure also leaves room to eventually add support for headers (and header size metrics). The PR also adds one missing field: we already had a field for the response body, and now we're adding a field for the request body.

[ruflin]

LGTM except changelog.

It's important that this is not a breaking change is it happened between releases. Otherwise we could never revert or experiment with things between releases.