-
Notifications
You must be signed in to change notification settings - Fork 339
[injection/sharedmain] OTel Support #3190
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
[injection/sharedmain] OTel Support #3190
Conversation
8fcfcd7 to
174f42a
Compare
174f42a to
412b5ee
Compare
1135ba7 to
b7cc628
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3190 +/- ##
==========================================
- Coverage 75.96% 75.91% -0.05%
==========================================
Files 205 205
Lines 11690 11709 +19
==========================================
+ Hits 8880 8889 +9
- Misses 2539 2547 +8
- Partials 271 273 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
evankanderson
left a comment
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.
A few comments about usage, but this makes sense to me overall.
| logger.Fatalw("Failed to setup trace provider", zap.Error(err)) | ||
| } | ||
|
|
||
| otel.SetTextMapPropagator(tracing.DefaultTextMapPropagator()) |
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.
This feels like it should be part of tracing.NewTracerProvider, even though it's actually a global spooky-action-at-a-distance manipulation. WDYT?
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.
tracing.NewTracerProvider
That doesn't actually set the global tracer in NewTracerProvider. We do that in sharedmain after setting the SetTextMapPropagator.
I prefer the observability package to not set any OTel globals.
| if _, err := client.Get(ctx, cmName, metav1.GetOptions{}); err == nil { | ||
| cmw.Watch(cmName, observers...) | ||
| } else if !apierrors.IsNotFound(err) { | ||
| logger.Fatalw("Error reading ConfigMap "+cmName, zap.Error(err)) |
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 assuming we don't have a way to notice if the ConfigMap shows up 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.
This file could use a cleanup - I've just changed the 'Watch' here but the diff shows a larger change.
Generally, I think the controllers should halt and wait if a config map is not present. I could imagine a split brain scenario occurring.
I'd rather not make those edits in this PR.
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.
That's fine. I'm slighly worried about "halt and catch fire" as a behavior when a configmap we ship has been removed. The idea of shipping them has mostly been about documentation, not about requiring them to have specific contents (or even be present) for things to function.
b7cc628 to
db3e763
Compare
|
I'm marking this ready - we can merge this and it will 'break' metrics/tracing @ HEAD - but I think that's worth it since it'll be easier to review and make follow up changes. Plus metrics/tracing would have already been 'broken' downstream if we merged pkg changes |
observability/resource/default.go
Outdated
|
|
||
| // Ignore the error because it complains about semconv | ||
| // schema version differences | ||
| resource, _ := resource.Merge( |
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.
there shouldn't be an error here anymore since the telemetry sdk attributes and resource now use the same semconv version.
But before if the semconv packages were different it would return this error with a resource without a schema
https://github.com/open-telemetry/opentelemetry-go/blob/957f4417b7719eeff17f051228520176fd2d5b78/sdk/resource/resource.go#L218
There was a bug in v1.36.0 where they didn't match up which was odd.
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 added a test and now we panic if there is an error.
We can always change this in the future if we find it annoying
|
/hold Actually I want to make another related change |
Cali0707
left a comment
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.
Just a few nits, but overall lgtm
Given Views in OTel are overrides for end-users this should really be a sharedmain option instead of a dedicated package. In OpenCensus views were required but in OTel they are not
|
Talking to the OTel folks - views are an 'end-user' override. Unlike OpenCensus they are not mandatory to get metrics export to work. So it seems more fitting to remove the global package I created and just make it a sharedmain option that controller authors can change. |
|
/hold cancel |
Cali0707
left a comment
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.
/lgtm
/hold in case @dprotaso wants more feedback from others
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Cali0707, dprotaso The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
evankanderson
left a comment
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 okay with this as-is, but I had a couple comments that didn't get sent this morning.
| if _, err := client.Get(ctx, cmName, metav1.GetOptions{}); err == nil { | ||
| cmw.Watch(cmName, observers...) | ||
| } else if !apierrors.IsNotFound(err) { | ||
| logger.Fatalw("Error reading ConfigMap "+cmName, zap.Error(err)) |
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.
That's fine. I'm slighly worried about "halt and catch fire" as a behavior when a configmap we ship has been removed. The idea of shipping them has mostly been about documentation, not about requiring them to have specific contents (or even be present) for things to function.
evankanderson
left a comment
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.
/lgtm
|
/hold cancel |
This stacks onto #3188