Any particular library might provide only a subset of these measures/views/tags. Check the language-specific documentation for the list of supported values.
As always, units are encoded according to the case-sensitive abbreviations from the Unified Code for Units of Measure:
Buckets for distributions in default views are as follows:
Client stats are recorded at the end of each outbound RPC.
Measure name | Unit | Description |
---|---|---|
grpc.io/client/sent_messages_per_rpc | 1 | Number of messages sent in the RPC (always 1 for non-streaming RPCs). |
grpc.io/client/sent_bytes_per_rpc | By | Total bytes sent across all request messages per RPC. |
grpc.io/client/received_messages_per_rpc | 1 | Number of response messages received per RPC (always 1 for non-streaming RPCs). |
grpc.io/client/received_bytes_per_rpc | By | Total bytes received across all response messages per RPC. |
grpc.io/client/roundtrip_latency | ms | Time between first byte of request sent to last byte of response received, or terminal error. |
grpc.io/client/server_latency | ms | Propagated from the server and should have the same value as “grpc.io/server/latency”. |
grpc.io/client/started_rpcs | 1 | The total number of client RPCs ever opened, including those that have not completed. |
All client metrics should be tagged with the following.
Tag name | Description |
---|---|
grpc_client_method | Full gRPC method name, including package, service and method, e.g. google.bigtable.v2.Bigtable/CheckAndMutateRow |
grpc_client_status | gRPC server status code received, e.g. OK, CANCELLED, DEADLINE_EXCEEDED |
grpc_client_method
is set when an outgoing request starts and is available in all the recorded
metrics.
grpc_client_status
is set when an outgoing request finishes and is only available around metrics
recorded at the end of the outgoing request.
Status codes should be stringified according to:
https://github.com/grpc/grpc/blob/master/doc/statuscodes.md
The following set of views are considered minimum required to monitor client-side performance:
View name | Measure | Aggregation | Tags |
---|---|---|---|
grpc.io/client/sent_bytes_per_rpc | grpc.io/client/sent_bytes_per_rpc | distribution | grpc_client_method |
grpc.io/client/received_bytes_per_rpc | grpc.io/client/received_bytes_per_rpc | distribution | grpc_client_method |
grpc.io/client/roundtrip_latency | grpc.io/client/roundtrip_latency | distribution | grpc_client_method |
grpc.io/client/completed_rpcs | grpc.io/client/roundtrip_latency | count | grpc_client_method, grpc_client_status |
grpc.io/client/started_rpcs | grpc.io/client/started_rpcs | count | grpc_client_method |
The following set of views are considered useful but not mandatory to monitor client side performance:
View name | Measure | Aggregation | Tags |
---|---|---|---|
grpc.io/client/sent_messages_per_rpc | grpc.io/client/sent_messages_per_rpc | distribution | grpc_client_method |
grpc.io/client/received_messages_per_rpc | grpc.io/client/received_messages_per_rpc | distribution | grpc_client_method |
grpc.io/client/server_latency | grpc.io/client/server_latency | distribution | grpc_client_method |
Server stats are recorded at the end of processing each RPC.
Measure name | Unit | Description |
---|---|---|
grpc.io/server/received_messages_per_rpc | 1 | Number of messages received in each RPC. Has value 1 for non-streaming RPCs. |
grpc.io/server/received_bytes_per_rpc | By | Total bytes received across all messages per RPC. |
grpc.io/server/sent_messages_per_rpc | 1 | Number of messages sent in each RPC. Has value 1 for non-streaming RPCs. |
grpc.io/server/sent_bytes_per_rpc | By | Total bytes sent in across all response messages per RPC. |
grpc.io/server/server_latency | ms | Time between first byte of request received to last byte of response sent, or terminal error. |
grpc.io/server/started_rpcs | 1 | The total number of server RPCs ever opened, including those that have not completed. |
All server metrics should be tagged with the following.
Tag name | Description |
---|---|
grpc_server_method | Full gRPC method name, including package, service and method, e.g. com.exampleapi.v4.BookshelfService/Checkout |
grpc_server_status | gRPC server status code returned, e.g. OK, CANCELLED, DEADLINE_EXCEEDED |
grpc_server_method
is set when an incoming request starts and is available in the context for
the entire RPC call handling.
grpc_server_status
is set when an incoming request finishes and is only available around metrics
recorded at the end of the incoming request.
Status codes should be stringified according to:
https://github.com/grpc/grpc/blob/master/doc/statuscodes.md
The following set of views are considered minimum required to monitor server side performance:
View name | Measure | Aggregation | Tags |
---|---|---|---|
grpc.io/server/received_bytes_per_rpc | grpc.io/server/received_bytes_per_rpc | distribution | grpc_server_method |
grpc.io/server/sent_bytes_per_rpc | grpc.io/server/sent_bytes_per_rpc | distribution | grpc_server_method |
grpc.io/server/server_latency | grpc.io/server/server_latency | distribution | grpc_server_method |
grpc.io/server/completed_rpcs | grpc.io/server/server_latency | count | grpc_server_method, grpc_server_status |
grpc.io/server/started_rpcs | grpc.io/server/started_rpcs | count | grpc_server_method |
The following set of views are considered useful but not mandatory to monitor server side performance:
View name | Measure | Aggregation | Tag |
---|---|---|---|
grpc.io/server/received_messages_per_rpc | grpc.io/server/received_messages_per_rpc | distribution | grpc_server_method |
grpc.io/server/sent_messages_per_rpc | grpc.io/server/sent_messages_per_rpc | distribution | grpc_server_method |
This way users can configure views to correlate incoming with outgoing requests. A view example:
View name | Measure | Aggregation | Tag |
---|---|---|---|
grpc.io/client/latency_by_server_method | grpc.io/client/roundtrip_latency | distribution | grpc_client_method, grpc_server_method |
This is TBD, eventually a designated gRPC metadata key will be specified for this purpose.
Error counts can be computed on your metrics backend by totalling the different per-status values.
They can be defined over any measure recorded once per RPC (since it’s just a count aggregation over the measure). It would be unnecessary to use a separate “count” measure.