## Goal Refine Praefect's apdex definition to be more meaningful, and make it easy to find the relevant gRPC calls in Kibana. ## Problem Praefect's apdex measurement is not currently useful. It ignores most gRPC calls, typically only counting `ServerInfo` and `VoteTransaction` gRPC calls, neither of which is user-facing and both of which are rare enough that even a single high-latency event can trigger an alert. We need to decide what we want Praefect's apdex latency to mean, and then document and implement that. Should it mimic Gitaly's apdex logic? Or it represent just the proxy-related gRPC calls? Also, we should make it easy to find in Kibana which logged gRPC calls contribute to a drop in the apdex. Currently it is very counter-intuitive. ## Background More details are in incident issue: https://gitlab.com/gitlab-com/gl-infra/production/-/issues/3244 But in summary: The Praefect proxy's latency apdex explicitly ignores 18 gRPC methods. Only a few other gRPC methods have non-zero counters in production. This lead to 2 false alarms about latency spiking due to just 3 slow gRPC calls. (Since the measurement window included less than 100 other gRPC calls, 3 was more than enough to exceed the apdex threshold.) More importantly, the apdex is currently not measuring anything meaningful. The only regularly occurring gRPC calls that match the apdex definition are: * `ServerInfo` * `VoteTransaction` Other gRPC methods can potentially match too, but they usually have zero-valued counters in Praefect. This epic arose out of a corrective action issue, per the comments below.