Support HTTP request/response size

[dipindas]

Please add support to get http response size as a metric value

[jkschneider]

Thanks. Surprised we didn't think of that earlier. Will do it with a DistributionSummary so you can best understand the distribution of response sizes over time.

Just requires a change to WebMvcMetricsFilter, et al and making the corresponding change in Spring Boot 2 and other web frameworks.

[mweirauch]

Just out of curiosity, would this include body-only-size or include the headers as well?

[shakuzen]

@mweirauch I think we should do both body and headers (with a tag?) as much as possible. Also, a separate metric for request and response sizes would be potentially useful.

[mweirauch]

Sounds good.
Would we be differentiating between server and client side instrumentation? Guess so.
So in analogy to http.server.requests and http.client.requests:
http.server.request.size and http.client.request.size? (Don't pin me on the naming.)

[izeye]

http.server.request.size and http.client.request.size? (Don't pin me on the naming.)

@mweirauch I guess you meant http.server.response.size and http.client.response.size?

[mweirauch]

Eek, things go wrong when doing stuff in between. What I meant was ...
http.server.[request,response].size for server (webmvc,jersey,webflux) instrumentation
and
http.client.[request,response].size for client (RestTemplate, okhttp?,...) instrumentation

[fzyzcjy]

Hi is there any updates (after 2 years)?

[drriguz]

Hi is there any updates (after 2 years)?

Hi is there any updates (after 3 years)?

[MayankManas1]

hi, is there any updates (after 4 years)?

[jonatan-ivanov]

There was:

shakuzen modified the milestones: 1.x, 1.11 backlog on Jan 31

It's not a guarantee that it will make it to 1.11 but issues like this (help-wanted label) are good for contributions if anyone wants to file a PR.

[babbarimam]

Hi @shakuzen ,
can you please confirm when and in which version we can expect the http response size metrics?
Thanks

[bclozel]

From a Framework instrumentation perspective:

An easy way to instrument this would be to read the Content-Length HTTP header - unfortunately a lot of requests and responses use Transfer-Encoding: chunked and the only way to know the actual size is to wrap the request/responses and count the bytes as they're being read. Because this can happen with blocking and non-blocking I/O at the Servlet level, this can be quite challenging to implement and could cause a significant performance drop.

Also, even if this first problem is solved, the message size at the web Framework level is not the same as the actual message size on the network. Servers and Servlet containers in general support message compression and perform this task on-the-fly. This means that this metric instrumentation would need to happen at the server level, not at the web framework level. This part is highlighted in the OTel semantic conventions as well and the metric itself is optional.

To summarize, I think that mentioning WebMvcMetricsFilter is misleading here as the instrumentation must happen at the level of the HTTP library (server or client). For example, developers would need to use a binder to instrument Tomcat, not rely on the instrumentation done at the Spring Framework/Spring Boot level.

I think the best way to make progress on this is to review the available binders for HTTP servers and clients, and figure out if this type of instrumentation is possible in an efficient manner for each.