-
Notifications
You must be signed in to change notification settings - Fork 431
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
Log SDK, OTLP builders to accept Resource directly instead of wrapping in Config #1788
Log SDK, OTLP builders to accept Resource directly instead of wrapping in Config #1788
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1788 +/- ##
=======================================
- Coverage 73.6% 73.6% -0.1%
=======================================
Files 124 123 -1
Lines 19517 19500 -17
=======================================
- Hits 14378 14362 -16
+ Misses 5139 5138 -1 ☔ View full report in Codecov by Sentry. |
This makes sense to me, I don't think we need Config, when there is already a builder for |
It's actually not meant to be a Builder. Rather than setter functions for |
The config feels like an unnecessary additional layering without adding any value. specifying Resource, via config:
vs directly specifying Resource. This looks cleaner in my opinion.
|
In practice the only difference is the option 1 requires users to be explicit on We can discuss more on the community call if needed |
Yes, but to be honest, lack of consistency is my main worry! Examples
Other than that, it is not clear what value it offers to end users.
vs
Not every config for provider is done via trace_config - eg: Processors are done differently, so users must now use both patterns to configure the provider. It feels a lot cleaner to offer every config via the existing builder pattern for provider_builder (and do it consistently across all signals/exporters. I'll propose additional changes to the way OTLP Pipeline is configured now in a separate PR.) |
It we want to converage into a single implementation shouldn't we do breaking changes on the signals that is less stable, in this case, metrics?
Batch config was consistent with the trace config until #1480 introduces a builder pattern. Given there are little logic from that builder, we should probably revert the changes.
I am not sure what's the two patterns here? I see |
The 2 patterns are:
I think you probably meant to say "logic of chosing processors (simple vs batch) for exporters" ? I mostly agree. Exporter is not something Provider should be aware of - provider only knows of processor/readers, and they in turn deal with exporter. I have some ideas to fix that. Even with that - there is still with_processor and other things like with_config(sampler,id etc.). What value does with_config provides compared to using the builder pattern on top of provider? |
As discussed offline with Zhongyang:
@TommyCpp Please feel to correct the above, if I captured everything correct or not! |
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, and agree with further refactoring of OTLP*Pipeline as discussed here.
/// The `Config` that this provider should use. | ||
pub fn with_config(self, config: Config) -> Self { | ||
Builder { config, ..self } | ||
/// The `Resource` to be associated with this Provider. |
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.
nit: can link the Resource
doc from sdk
#1810 Opened this issue to get some feedback. |
…g in Config (open-telemetry#1788) Co-authored-by: Zhongyang Wu <zhongyang.wu@outlook.com>
Logs sdk and otlp pipeline builders now accept Resource directly in their builders, instead of having to wrap inside Config. For logs,
Resource
was the only thing insideConfig
anyway, but even if there were more concepts to be added later, the builders can accept them directly. (If, more memory efficiency reasons, we need to wrap things under, it can be an internal implementation detail, achievable without public api changes.)Tracing still has
Config
with idgen,sampler, resource etc, and builders acceptingConfig
only. It is a bit odd to use, asConfig
itself has own builders but without thebuild()
method! If there is agreement, I can do similar changes for Traces too.