Proposal: Request Durations in Load Stats Reporting
- Dominant language
- C++
- Stars
- 28.9k
- Forks
- 5.6k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 428
Description
I'm pretty new to Envoy, so apologies in advance if this is a silly question.
Envoy's load stats reporting currently reports useful metrics like [total_successful_requests](https://github.com/envoyproxy/envoy/blob/570f7ac553e64206193d64952bf8d4a72b76e49c/api/envoy/config/endpoint/v3/load_report.proto#L36) and `total_requests_in_progress`. I'm looking to implement a server that can estimate the long term average number of requests in our system via [Little's Law](https://en.wikipedia.org/wiki/Little%27s_law). For that, I think we'd need `total_requests_in_progress`, and some notion of the average processing time of each request, broken down by cluster.
Envoy currently reports statistics that include the histogram [upstream_rq_time](https://www.envoyproxy.io/docs/envoy/latest/configuration/upstream/cluster_manager/cluster_stats.html?highlight=upstream_rq_timeout#dynamic-http-statistics), which is precisely what we'd need.
I wonder if this metric, or simply an "average request time" per cluster, should be threaded through to the load reporting stats. If yes, any pointers on a good way to implement it would be appreciated, and I can send a PR. Otherwise, the alternate path I see is that we need our server to be a full fledged gRPC metrics sink, which would work, but seems like a hack.
I also noticed some work around [Orca](https://github.com/envoyproxy/envoy/issues/6614) and I wonder if the recommendation is to wait until that work is complete.
Contributor guide
Assessment
This issue has not been assessed yet.