OpenTelemetry & SpringBoot

[ziomill]

Hi all,

I'm trying to add OpenTelemetry in some microservices based on SpringBoot.
The main goal is to use manual instrumentation in order to collect metrics.

The docs says that;
"you need to configure an instance of the OpenTelemetrySdk as early as possible in your application"
and report this example:

SdkTracerProvider sdkTracerProvider = SdkTracerProvider.builder()
  .addSpanProcessor(BatchSpanProcessor.builder(OtlpGrpcSpanExporter.builder().build()).build())
  .build();

SdkMeterProvider sdkMeterProvider = SdkMeterProvider.builder()
  .registerMetricReader(PeriodicMetricReader.builder(OtlpGrpcMetricExporter.builder().build()).build())
  .build();

OpenTelemetry openTelemetry = OpenTelemetrySdk.builder()
  .setTracerProvider(sdkTracerProvider)
  .setMeterProvider(sdkMeterProvider)
  .setPropagators(ContextPropagators.create(W3CTraceContextPropagator.getInstance()))
  .buildAndRegisterGlobal();

I have two questions about this approach:

1. What if I don't configure the SDK (for example, suppose that one would use the default configuration) ? Can I avoid the explicit OpenTelemetry configuration?

2. I'm retrieving the OpenTelemetry instance during the application startup, handling it as Singleton bean. Looking at the javadoc it seems that the use of GlobalOpenTelemetry should be avoided. In case, what is the right way to obtain an OpenTelemetry instance?

@Configuration
public class OpenTelemetryConfig {

    @Bean
    public OpenTelemetry buildOpenTelemetry() {
        OpenTelemetry openTelemetry = GlobalOpenTelemetry.get();
        return openTelemetry;
    }
}

Thank you

[mateuszrzeszutek]

Hey @ziomill ,

1. What if I don't configure the SDK (for example, suppose that one would use the default configuration) ? Can I avoid the explicit OpenTelemetry configuration?

You'll get a no-op implementation, which is most likely not what you want at all.

2. I'm retrieving the OpenTelemetry instance during the application startup, handling it as Singleton bean. Looking at the javadoc it seems that the use of GlobalOpenTelemetry should be avoided. In case, what is the right way to obtain an OpenTelemetry instance?

GlobalOpenTelemetry is pretty much only for the javaagent coop, you shouldn't use it in manually instrumented application code (well, it's generally a good idea to avoid globals anyway).

There are a couple of ways you could implement that:

1. You could construct the SDK by hand, as in the example you quoted, and expose it as a Spring bean (possibly without registering as a global).

2. You could use the autoconfigure module to set up the SDK using env variable and/or system property configuration

   @Bean
   public OpenTelemetry openTelemetry() {
     return AutoConfiguredOpenTelemetrySdk.builder()
         .setResultAsGlobal(false) // optionally disable the global registration
         .build();
   }

3. Or you could use the OTel Spring auto-configure module and just add @EnableOpenTelemetry to your app. Please note that this one is still somewhat unstable, and there will be breaking changes (especially in the configuration property names) in the future.

[ziomill]

Thank you @mateuszrzeszutek for your clear explanation.

I really appreciate the OTel Spring auto-configure module and I will use it for sure when it will become stable.

Wanting to use the autoconfigure module (point 2), what does the "setResultAsGlobal" mean? What is the difference between Global/Not Global config?

[mateuszrzeszutek]

It does not set the result of the auto-configuration as GlobalOpenTelemetry. This is something you might or might not want to do, depending on how your application is structured (e.g. if there's any chance of multiple registration).

[davidtam]

Hello @mateuszrzeszutek thanks for this - this post has help me enormously.

I think I got something working now - I am happy to contribute add an working helloworld example to the starter repo or perhaps the autoconfig repo if this would help?

Also as a side note - am I understanding it correctly that all these maven artifact with -alpha are subject to break changes?

Thank you!!

[mateuszrzeszutek]

Hey @davidtam ,

Sorry for the (very) late reply, at some point I got kinda overwhelmed with GH notifications and I'm still in the process of clearing them up 🙈

I think I got something working now - I am happy to contribute add an working helloworld example to the starter repo or perhaps the autoconfig repo if this would help?

I think we already have an autoconfigure example here - if you find anything you would want to add there, by all means, please create an issue/PR!

Also as a side note - am I understanding it correctly that all these maven artifact with -alpha are subject to break changes?

Yes, that is correct.