Define the metrics that we expect to capture from RPC integrations

[mtwo]

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

[fbogsany]

Errors per second?

[mtwo]

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

[Oberon00]

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.

[mtwo]

@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

[bogdandrutu]

Closing this as a duplicate of #1016