-
Notifications
You must be signed in to change notification settings - Fork 858
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 enhanced SDK autoconfig for exporters #6368
add enhanced SDK autoconfig for exporters #6368
Conversation
@jack-berg please let me know what you think. I'm open to putting the code somewhere else (or make it package protected to indicate incubating) if the general approach seems useful. |
As an additional motivation - here's a strange issue you run into, if you forget to do https://github.com/open-telemetry/opentelemetry-java/pull/6368/files#diff-15418caefc3f4f5fdd4fb6eb9594078b40b40544d38f9a7f99a3819de0146e4aR105 This is the issue: open-telemetry/opentelemetry-java-instrumentation#11052 (comment) |
I think there's an easier way to accomplish this:
If this is a pattern we to be common, I'd be more interested in fixing the public API surface area than extending the internal APIs and encouraging their use. For example, we could add an overload for obtaining a builder which is prepopulated with the config from a
But why not use |
I didn't realize that there's a void init() {
AutoConfiguredOpenTelemetrySdkBuilder builder = AutoConfiguredOpenTelemetrySdk.builder();
builder.addSpanExporterCustomizer(
(exporter, config) -> ((OtlpHttpSpanExporter) exporter).toBuilder().setHeaders(this::headers).build());
}
private Map<String, String> headers() {
return null;
} |
Just confirming this here - you would need to check the type of the exporter before type casting it when using AutoConfiguredOpenTelemetrySdk, correct ? I was doing something similar recently and found that all those if based type checks make the code a little verbose and was wondering if there are ways to avoid the type checks? |
grpc and http builders have different properties - not sure how you'd avoid the type cast (all but 3 options are identical - so it would be possible to extract an interface) |
+1 to extracting an interface out of it. IIUC, the proposed interface would attempt to unify the |
I just tried it out.
|
Superceded by open-telemetry/opentelemetry-java-examples#394 |
In open-telemetry/opentelemetry-java-examples#378 - you can see that it's quite difficult to create exporters programmatically - which also respect all config properties.
This PR tries to make this easier.
For the purpose of discussing the approach, only the span exporter is enhanced - but the approach can be used for metrics and logs, too.