-
Notifications
You must be signed in to change notification settings - Fork 174
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.
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
Add attributes request/response body size for rpc #1281
Open
crossoverJie
wants to merge
20
commits into
open-telemetry:main
Choose a base branch
from
crossoverJie:rpc-attr-body
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
20 commits
Select commit
Hold shift + click to select a range
2d1d094
add attribute for rpc
crossoverJie 4328535
add changelog
crossoverJie ca94a14
add issues id
crossoverJie 7f370ca
fix with cr
crossoverJie 9b422fb
Merge branch 'main' into rpc-attr-body
crossoverJie a9ba7d2
add grpc body size description
crossoverJie f8aabcf
Merge branch 'main' into rpc-attr-body
crossoverJie e468b26
fix ci
crossoverJie e63d2f6
fix ci
crossoverJie e60455b
Merge branch 'main' into rpc-attr-body
crossoverJie 47fa148
Merge master
crossoverJie 0cfee17
Update model/registry/rpc.yaml
crossoverJie 9aef0f4
Update model/registry/rpc.yaml
crossoverJie eacb4a1
Update model/trace/rpc.yaml
crossoverJie e06b9e1
Update model/trace/rpc.yaml
crossoverJie 2e0e628
Merge branch 'main' into rpc-attr-body
crossoverJie 1da2208
merge CR
crossoverJie 228457e
fix ci
crossoverJie 80e7bd2
fix ci
crossoverJie 9d4c250
Merge branch 'main' into rpc-attr-body
crossoverJie File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,22 @@ | ||
# Use this changelog template to create an entry for release notes. | ||
# | ||
# If your change doesn't affect end users you should instead start | ||
# your pull request title with [chore] or use the "Skip Changelog" label. | ||
|
||
# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix' | ||
change_type: enhancement | ||
|
||
# The name of the area of concern in the attributes-registry, (e.g. http, cloud, db) | ||
component: rpc | ||
|
||
# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`). | ||
note: add rpc request/response body size attributes | ||
|
||
# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists. | ||
# The values here must be integers. | ||
issues: [1281] | ||
|
||
# (Optional) One or more lines of additional information to render under the primary note. | ||
# These lines will be padded with 2 spaces and then inserted directly into the document. | ||
# Use pipe (|) for multiline entries. | ||
subtext: |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious what gRPC team (summoning @yashykt) think about this.
I know we avoided having this value as a metric because of possible misinterpretation of behavior between streaming/unary, but having this only used for Span generation may be ok.
Is it possible that users could try to aggregate over this value and lose valuable o11y because of it? Should we have a "is_streaming" or some such flag on Spans so we can make sure we don't aggregate things and make false assumptions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming we record metrics, we'd need to record direction as a part of the metric name - something like
rpc.sent.message.size
,rpc.received.message.size
(histograms).We could use similar naming (
rpc.sent.message.size
,rpc.received.message.size
) for these attributes and replace existing ones (rpc.message.*_size
) populated on the events.Unary calls then could be recorded without events - there is nothing(?) useful on the unary messages besides size anyway (direction is now part of the name and index is always 0). Having everything on one span would be easy and convenient for the simple case.
Streaming calls would not have size attributes on spans - they would always be reported on events to avoid potential ambiguity/confusion.
Would this work? @jsuereth @crossoverJie @yashykt
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The wording here that says "message payload that is sent over the wire" is kinda confusing because after a payload is serialized, we could compress it, translate it to HTTP2 using https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md and then encrypt it as well.
The part where it says "In case of streaming calls, it accounts for the original message in the request and does not include size of the consequent message stream." also seems like a big restriction.
I'm slightly confused whether this is meant for metrics or tracing, but I'll assume that this is for tracing. Refer to https://github.com/grpc/proposal/blob/master/A72-open-telemetry-tracing.md, for the gRPC team's design. Essentially, the gRPC team decided to always use events for recording message sizes irrespective of whether we are using unary or streaming. This keeps things sane and as a side-benefit, if we can record separate events for the compressed and uncompressed size, this also allows us to gain some insight on when a message was compressed/decompressed and how much time that took.