Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

A66 and A78 update: Add value type (integer/floating-point) to metrics #432

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

A66 and A78 update: Add value type (integer/floating-point) to metrics #432

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 11 additions & 10 deletions A66-otel-stats.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
# OpenTelemetry Metrics

* Author: Yash Tibrewal (@yashykt), Zach Reyes (@zasweq), Vindhya Ningegowda (@DNVindhya), Xuan Wang (@XuanWang-Amos)
* Author: Yash Tibrewal (@yashykt), Zach Reyes (@zasweq), Vindhya Ningegowda
(@DNVindhya), Xuan Wang (@XuanWang-Amos)
* Approver: Mark Roth (@markdroth)
* Status: Final
* Implemented in: <language, ...>
Expand Down Expand Up @@ -406,22 +407,22 @@ the data.
* **grpc.client.attempt.started** <br>
The total number of RPC attempts started, including those that have not completed. <br>
*Attributes*: grpc.method, grpc.target <br>
*Type*: Counter <br>
*Type*: Counter (integer) <br>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we might want to say something more precise than just "integer" vs. "floating point". For example, would it be okay for a gRPC implementation to use a 32-bit integer here? I assume not, in which case we need language here saying so.

*Unit*: `{attempt}` <br>
* **grpc.client.attempt.duration** <br>
End-to-end time taken to complete an RPC attempt including the time it takes to pick a subchannel. <br>
*Attributes*: grpc.method, grpc.target, grpc.status <br>
*Type*: Histogram (Latency Buckets) <br>
*Type*: Histogram (floating-point)(Latency Buckets) <br>
*Unit*: `s` <br>
* **grpc.client.attempt.sent_total_compressed_message_size** <br>
Total bytes (compressed but not encrypted) sent across all request messages (metadata excluded) per RPC attempt; does not include grpc or transport framing bytes. <br>
Attributes: grpc.method, grpc.target, grpc.status <br>
Type: Histogram (Size Buckets) <br>
Type: Histogram (integer)(Size Buckets) <br>
*Unit*: `By` <br>
* **grpc.client.attempt.rcvd_total_compressed_message_size** <br>
Total bytes (compressed but not encrypted) received across all response messages (metadata excluded) per RPC attempt; does not include grpc or transport framing bytes. <br>
*Attributes*: grpc.method, grpc.target, grpc.status <br>
*Type*: Histogram (Size Buckets) <br>
*Type*: Histogram (integer)(Size Buckets) <br>
*Unit*: `By` <br>

#### Client Per-Call Instruments
Expand All @@ -432,32 +433,32 @@ the data.
End timestamp - Before the status of the RPC is delivered to the application. <br>
If the implementation uses an interceptor then the exact start and end timestamps would depend on the ordering of the interceptors. Non-interceptor implementations should record the timestamps as close as possible to the top of the gRPC stack, i.e., payload serialization should be included in the measurement. <br>
*Attributes*: grpc.method, grpc.target, grpc.status <br>
*Type*: Histogram (Latency Buckets) <br>
*Type*: Histogram (floating-point)(Latency Buckets) <br>
*Unit*: `s` <br>

#### Server Instruments

* **grpc.server.call.started** <br>
The total number of RPCs started, including those that have not completed. <br>
*Attributes*: grpc.method <br>
*Type*: counter <br>
*Type*: counter (integer)<br>
*Unit*: {call} <br>
* **grpc.server.call.sent_total_compressed_message_size** <br>
Total bytes (compressed but not encrypted) sent across all response messages (metadata excluded) per RPC; does not include grpc or transport framing bytes. <br>
*Attributes*: grpc.method, grpc.status <br>
*Type*: Histogram (Size Buckets) <br>
*Type*: Histogram (integer)(Size Buckets) <br>
*Unit*: `By` <br>
* **grpc.server.call.rcvd_total_compressed_message_size** <br>
Total bytes (compressed but not encrypted) received across all request messages (metadata excluded) per RPC; does not include grpc or transport framing bytes. <br>
*Attributes*: grpc.method, grpc.status <br>
*Type*: Histogram (Size Buckets) <br>
*Type*: Histogram (integer)(Size Buckets) <br>
*Unit*: `By` <br>
* **grpc.server.call.duration** <br>
This metric aims to measure the end2end time an RPC takes from the server transport’s (HTTP2/ inproc) perspective. <br>
Start timestamp - After the transport knows that it's got a new stream. For HTTP2, this would be after the first header frame for the stream has been received and decoded. Whether the timestamp is recorded before or after HPACK is left to the implementation. <br>
End timestamp - Ends at the first point where the transport considers the stream done. For HTTP2, this would be when scheduling a trailing header with END_STREAM to be written, or RST_STREAM, or a connection abort. Note that this wouldn’t necessarily mean that the bytes have also been immediately scheduled to be written by TCP. <br>
*Attributes*: grpc.method, grpc.status <br>
*Type*: Histogram (Latency Buckets) <br>
*Type*: Histogram (floating-point)(Latency Buckets) <br>
*Unit*: `s` <br>

### Migration from OpenCensus
Expand Down
Loading