Use NoopLogEmitterBuilder when no log processors are registered

[jack-berg]

Currently if no log processors are registered, a NoopLogProcessor is used. This drops emitted log records, but the log sdk can still use memory to maintain the map of instrumentation scope to SdkLogEmitter in the ComponentRegistry.

This optimizes SdkLogEmitterProvider by returning a NoopLogEmitterBuilder when no log processors are registered. Note that metrics already has a similar optimization. Tracing doesn't, but IIRC correctly there's a reason for that 🤔 that we've previously discussed.

[codecov[bot]]

Codecov Report

Merging #4672 (be29403) into main (b979ea1) will increase coverage by 0.05%. The diff coverage is 100.00%.

@@             Coverage Diff              @@
##               main    #4672      +/-   ##
============================================
+ Coverage     90.04%   90.09%   +0.05%     
- Complexity     5086     5091       +5     
============================================
  Files           586      587       +1     
  Lines         15707    15727      +20     
  Branches       1507     1508       +1     
============================================
+ Hits          14143    14169      +26     
+ Misses         1109     1103       -6     
  Partials        455      455              

Impacted Files	Coverage Δ
.../opentelemetry/sdk/logs/LogEmitterSharedState.java	100.00% <100.00%> (ø)
.../opentelemetry/sdk/logs/NoopLogEmitterBuilder.java	100.00% <100.00%> (ø)
.../opentelemetry/sdk/logs/SdkLogEmitterProvider.java	100.00% <100.00%> (ø)
...ava/io/opentelemetry/sdk/internal/RateLimiter.java	94.11% <0.00%> (-5.89%)	:arrow_down:
...telemetry/sdk/trace/export/BatchSpanProcessor.java	93.10% <0.00%> (+0.68%)	:arrow_up:
...entelemetry/sdk/logs/export/BatchLogProcessor.java	89.47% <0.00%> (+4.51%)	:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[trask]

Tracing doesn't, but IIRC correctly there's a reason for that 🤔 that we've previously discussed.

maybe to keep trace context propagation enabled even if no (local) exporting?

[trask]

Tracing doesn't, but IIRC correctly there's a reason for that 🤔 that we've previously discussed.

maybe to keep trace context propagation enabled even if no (local) exporting?

this doesn't seem related though... 🤔x2

[jack-berg]

Tracing doesn't, but IIRC correctly there's a reason for that 🤔 that we've previously discussed.

maybe to keep trace context propagation enabled even if no (local) exporting?

this doesn't seem related though... 🤔x2

I did some testing to better undertand. If I setup an OpenTelemetry with a propagator and an SdkTracerProvider, with no processor, trace / span ids are generated and propagated:

    OpenTelemetry openTelemetry =
        OpenTelemetrySdk.builder()
            .setPropagators(ContextPropagators.create(W3CTraceContextPropagator.getInstance()))
            .setTracerProvider(SdkTracerProvider.builder().build())
            .build();

    try (Scope ignored = openTelemetry.getTracer("tracer").spanBuilder("span").startSpan().makeCurrent()) {
      openTelemetry.getPropagators().getTextMapPropagator().inject(
          Context.current(),
          new HashMap<>(),
          (carrier, key, value) -> {
            if (carrier != null) {
              System.out.println("inject key: " + key + ", value: " + value);
              carrier.put(key, value);
            }
          });

// produces:
// inject key: traceparent, value: 00-19cd01558e04d0866a6b35f752e5794f-651a40fe92bba5cf-01

However, if I were to make this same change on the SdkTracerProvider, the same setup would produce noop spans and no context is propagated.

So the existence of a functional Tracer implementation that produces real spans seems required for trace context to be generated and context propagation to work, even if there are no span processors listening for those spans.

Logs are different because there is nothing that can make use of a functional LogEmitter besides the LogProcessor.