-
Notifications
You must be signed in to change notification settings - Fork 16
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
pkg/loop: use beholder #696
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -12,7 +12,9 @@ import ( | |
) | ||
|
||
// Pointer to the global Beholder Client | ||
var globalClient = defaultClient() | ||
var globalClient atomic.Pointer[Client] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is to sync access within the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There is an exported |
||
|
||
func init() { globalClient.Store(NewNoopClient()) } | ||
|
||
// SetClient sets the global Beholder Client | ||
func SetClient(client *Client) { | ||
|
@@ -41,13 +43,6 @@ func GetEmitter() Emitter { | |
return GetClient().Emitter | ||
} | ||
|
||
func defaultClient() *atomic.Pointer[Client] { | ||
ptr := &atomic.Pointer[Client]{} | ||
client := NewNoopClient() | ||
ptr.Store(client) | ||
return ptr | ||
} | ||
|
||
// Sets global OTel logger, tracer, meter providers from Client. | ||
// Makes them accessible from anywhere in the code via global otel getters. | ||
// Any package that relies on go.opentelemetry.io will be able to pick up configured global providers | ||
|
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.
@pkcll @patrickhuie19 Does this optional config for an additional exporter make sense? Or should we consider other alternatives?
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.
Passing the configured exporter is more of a dependency injection rather than part of the config. Passing an exporter as part of the config seems like mixing different types of code aspects.
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 see 4 options:
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.
What does the TraceSpanExporter do on top of everything else configured in
opts
?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 is one approach to bridging the two tracing systems.
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.
It adds an additional exporter. It does not replace the normal one. They are accumulated: https://github.com/open-telemetry/opentelemetry-go/blob/main/sdk/trace/provider.go#L338
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.
You are right.
Do you see use case for having two separate trace processors/exporters for loop/server otel instrumentation and beholder Tracer (which will be used for producing custom traces from code)?
This kind of setup makes sense when you have two separate targets for otel-collector which is not the case with chainlink nodes.
This will result in duplicated traces being sent to the same collector if the target is the same.
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.
@jmank88 @patrickhuie19, ^^^ 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.
We could add a check for duplicate endpoints. But otherwise using both at the same time is not inherently problematic, and having the flexibility will make it easier to transition as well as support non-production cases.
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.
Makes sense