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.
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
stats/opentelemetry: Introduce Tracing API #7852
base: master
Are you sure you want to change the base?
stats/opentelemetry: Introduce Tracing API #7852
Changes from all commits
fc09e2c
2747371
96f92a0
f650e37
175d4c5
c30c44a
90ffa23
2083830
e8e9d53
57fd38a
b0aad8a
8680ae8
98d11b7
d0e1a0a
b6503f7
b2831f1
1cb4396
b8fe8db
d4ae3ab
c705b97
5571e3b
6e06350
cfb92ae
72e178b
5beafe1
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Check failure on line 17 in experimental/opentelemetry/trace_options.go
GitHub Actions / tests (vet, 1.22)
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.
Is this the right behavior? Shouldn't we default to our TestMapPropagator implementation, rather than requiring it to be set / doing something suboptimal if it's not?
It seems like that would be my last choice for behavior. If it's unset, I'd rather either fail to initialize (if TracerProvider is also set) or use our default TextMapPropagator.
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.
Updated.
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.
@dfawley as per the proposal, we shouldn't use any default propagator. The recommendation from OpenTelemetry is to use
W3CContextPropagator
which deals with text keys and values. TheGRPCTraceBinPropagator
that we have created is only suppose to be used for backward compatibility if someone is using opencensus plugin and they want to migrate to opentelemetry plugin.So, TextMapPropagator is a mandatory field which user has to set in dial option or server option. If they don't the code won't be instrumented
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 fine with that, but then we should error at initialization time if
TracerProvider
is set andTextMapPropagator
is not, shouldn't we? And if neither is set then we can just not do any tracing.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.
Sorry, it looks like we can't error from this API anyway, since it just returns a DialOption/ServerOption.
Should we log a warning? If you're setting tracing but you don't have a propagator, that seems not very useful? Or is this actually a reasonable configuration? In our opencensus code, I don't think there's any way to disable the span propagation.
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.
yeah i think logging warning is reasonable if you have set only one of TracerProvider and TextMapPropagator.
Its not reasonable. The code will just panic at some point if both are not set.
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.
@purnesh42H
How much code & data is shared between the tracing and metrics implementations? I don't believe they share almost anything?
Would it make sense to implement a separate set of interceptors for tracing & metrics so that we can avoid checking to see which one is implemented for every event in the life of an RPC? I think the code would end up simpler/cleaner/easier to review that way, too.
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.
@dfawley they only share the DialOption and ServerOption as per proposal. Are you suggesting to have 4 interceptors internally? Both stream and unary each for metrics and traces? If/When we add logging, we will add 2 more then. But yeah we will have separate path for each and then don't have to check if the other one is implemented as well.
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.
Yes, I think it would helpful to have separate handlers for the different functionality, since they share nothing in common and can be enabled/disabled independently.
Check warning on line 148 in stats/opentelemetry/client_metrics.go
Codecov / codecov/patch
stats/opentelemetry/client_metrics.go#L147-L148
Check warning on line 50 in stats/opentelemetry/client_tracing.go
Codecov / codecov/patch
stats/opentelemetry/client_tracing.go#L48-L50