Skip to content
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

Add get{Signal}Exporter methods to Simple{Signal}Processor, Batch{Signal}Processor #6078

Merged
merged 1 commit into from
Mar 22, 2024

Conversation

jack-berg
Copy link
Member

@jack-berg jack-berg commented Dec 14, 2023

Originally discussed in this comment, the idea is to make AutoConfigurationCustomizer#addSpanProcessorCustomizer more useful by allowing you to extract the configured SpanExporter/LogRecordExporter from the processor, and plug it into your own processor.

autoConfiguration.addSpanProcessorCustomizer(
        (spanProcessor, configProperties) -> {
          if (spanProcessor instanceof BatchSpanProcessor) {
            SpanExporter exporter = ((BatchSpanProcessor) spanProcessor).getExporter();
            return new MyCustomProcessor(exporter);
          }
          return spanProcessor;
        });

@jack-berg jack-berg requested a review from a team December 14, 2023 23:00
Copy link

codecov bot commented Dec 14, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (ffd53c7) 91.11% compared to head (40fe6bb) 91.09%.

Additional details and impacted files
@@             Coverage Diff              @@
##               main    #6078      +/-   ##
============================================
- Coverage     91.11%   91.09%   -0.03%     
- Complexity     5736     5739       +3     
============================================
  Files           628      628              
  Lines         16810    16814       +4     
  Branches       1662     1662              
============================================
- Hits          15317    15316       -1     
- Misses         1028     1035       +7     
+ Partials        465      463       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@jkwatson
Copy link
Contributor

jkwatson commented Jan 2, 2024

I'm not necessarily opposed to this approach, but it does feel like a band-aid on something that should be easier to do with auto-configuration.

I don't have a concrete proposal, but what if we had some sort of "autoconfiguration context" that stored all of the currently available auto-configured things, so that any customizer would be able to grab what it needs. It might mean a re-think of the whole auto-configuration codebase/SPIs, though. 🤔

@jack-berg
Copy link
Member Author

My thought is that this is sort of the like the pattern of adding toBuilder methods. The design question is whether or not we want users to be able to introspect on the configuration of components, or have them be black boxes. Personally, I don't see any advantage to keeping them black boxes. Sure there's more surface area, but its trivial to maintain and hard to imagine abuse.

It might mean a re-think of the whole auto-configuration codebase/SPIs, though.

I think the design of autoconfigure and the SPIs is pretty good, and don't have interest in boiling the ocean to solve this problem. One related option I've thought about is to ensure we have public APIs for all the places where we interpret ConfigProperties and return SDK components. For example, we could add a public static BatchSpanProcessor createProcessor(ConfigProperties, SpanExporter), and public static SpanExporter createSpanExporter(SpanExporter). This would allow users to cherry pick portions of autoconfigure they want to use. We already to this to some extent with ResourceConfiguration#createEnvironmentResource.

But I'm not inclined to do this without more conversation / motivating use cases because it would require adding a bunch of new surface area.

@jkwatson
Copy link
Contributor

jkwatson commented Jan 2, 2024

👍🏽 before we merge, are we sure the user from that conversation still needs this?

@jack-berg
Copy link
Member Author

👍🏽 before we merge, are we sure the user from #5986 (comment) still needs this?

I don't think its strictly necessary since in that case they want to wrap the batch processor instead of replacing it (from what I can gather). But I've personally had use cases where I wanted to replace the batch processor altogether: I wanted to ensure that all spans associated with a particular local root (typically all spans with a particular web request) were guaranteed to be exported in the same batch. This would allow the collector to do a sort of tail based sampling using all spans of request, but which does not require the normal resource intensive / complex routing associated with typical tail sampling where all spans of an entire trace are accumulated before making the decision.

In this case, I am still sending batches of spans to a span exporter, but according to different rules than the batch span processor.

Copy link
Contributor

@breedx-splk breedx-splk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like a reasonable approach to me. 👍🏻

@jack-berg
Copy link
Member Author

Will merge this if there are no additional comments.

@jack-berg jack-berg merged commit b897510 into open-telemetry:main Mar 22, 2024
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants