envoyproxy / envoyproxy/envoy

Proposal: Request Durations in Load Stats Reporting

Open
#11,599 13 comments 0 reactions 0 assignees View on GitHub
enhancement help wanted
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.