feat: Add customizers for processors and readers
This change introduces new customization points in OpenTelemetryRumBuilder for more advanced configuration of the OTel SDK.
It is now possible to:
- Customize the
BatchSpanProcessorBuilder,BatchLogRecordProcessorBuilder, andPeriodicMetricReaderBuilderbefore the components are built. - Wrap or replace the final
SpanProcessor,LogRecordProcessor, andMetricReaderinstances.
This allows for intercepting and modifying telemetry signals without needing to add extra processors or readers via the provider customizers.
The committers listed above are authorized under a signed CLA.
- :white_check_mark: login: agrognetti / name: Agustin Grognetti (345f6d8bda878db3a496c46502fa44738094d7d3, b7fb9cd0f849388bf5deef2f8a3bda5f606221be, bf3daaeee0fb40a7458e3db52cd0ab1518beddd9)
Codecov Report
:white_check_mark: All modified and coverable lines are covered by tests.
:white_check_mark: Project coverage is 63.75%. Comparing base (b228327) to head (bf3daae).
:warning: Report is 32 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #1389 +/- ##
==========================================
+ Coverage 63.30% 63.75% +0.45%
==========================================
Files 158 158
Lines 3109 3170 +61
Branches 320 324 +4
==========================================
+ Hits 1968 2021 +53
- Misses 1046 1054 +8
Partials 95 95
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
Hey @agrognetti thanks for this PR, and so sorry that it's taken this long to reply to you. We are in the process of releasing our first stable 1.0.0 version, and that effort has grabbed quite a bit of our attention.
It looks like your changes have a conflict now, largely due to the OpenTelemetryRumBuilder have been migrated to kotlin from java. Sorry that got changed out from under you...but this really cannot be merged (or reviewed) in its current state now.
I think this PR is probably a welcome change for advanced users who use the core module (via OpenTelemetryRumBuilder) directly, but I think it could also be helpful for us to hear about your specific use cases. What, specifically, are you hoping to accomplish with these customizers that could not be handled as easily with the existing mechanisms?
It would be helpful for us to understand this, because we intend for the OpenTelemetryRumBuilder to really only be used in advanced cases and not required for most users. Most users should just use the OpenTelemetryRumInitializer. When additional advanced customizations are needed, the OpenTelemetryRumBuilder should already provide a way to do virtually all programmatic SDK customizations that are available...but I get the impression that you wanted these to be easier? I worry slightly that these additional extension points might encourage users to use this, instead of the initializer.
Your feedback is helpful, so thanks in advance!
Another small piece of feedback -- even tho this PR isn't that huge, it might be helpful to break this into 3 separate PRs, each with their specific customization responsibility. Not required, just an idea to help things flow more easily.