Define the metrics that we expect to capture from RPC integrations

[Morgan McLean]

This is out of scope for beta, in scope for RC and beyond

While we have (somewhat) clear expectations of the spans and annotations that we expect tracing integrations to capture from RPC clients and servers, this isn't the case for metrics integrations. I propose that RPC integrations should capture the following metrics by default:

• Request / response latency, in milliseconds
• Throughput, in queries per second, broken down by status / response code

[Francis Bogsanyi]

Errors per second?

[Morgan McLean]

@fbogsany would queries per second with aggregation by status code (or equivalent) satisfy that?

[Christian Neumüller]

I think there are many metrics that could be generated on the back end out of the received spans & traces. Duplicating these metrics on the client side might be helpful in case we sample though.

[Morgan McLean]

@fbogsany edited the issue to specify that QPS metrics should be broken down by status code
@Oberon00 edited the issue to specify that this should be done for clients and servers

[Bogdan Drutu]

Closing this as a duplicate of #1016