Allow registering exporters without exposing BatchSpanProcessor as a type

[anuraaga]

What are you trying to achieve?

Simplify user experience for registering exporters

Additional context.

Is is allowed to expose batching as an option when registering an exporter?

// Default batch span processor settings
addExporter(exporter);

// Customize batch span processor settings
addExporter(exporter, BatchSettings.builder().set....build());

// simple span processor
addExporter(exporter, BatchSettings.noBatching());

The required span processors of the spec are there, but not exposed as types. It allows simple task of registering an exporter not require knowing the concept of span processors which seems like a nice UX.

open-telemetry/opentelemetry-java#2398

[Oberon00]

It seems like it would remove functionality for the user if there is no way to create a BatchSpanProcessor without directly attaching it to a TracerProvider (that would be the part before the addExporter that you left out above, right?). Maybe someone wants to build some filtering span processor that forwards only spans matching some criteria to a wrapped BatchSpanProcessor?
The spec calls out that scenario (I think) when it says in https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/sdk.md#span-processor:

SDK MUST allow users to implement and configure custom processors and decorate built-in processors for advanced scenarios such as tagging or filtering.

[anuraaga]

addSpanProcessor would still exist for tagging in onStart as an advanced operation but not required just to add an exporter. Tagging can't happen in onEnd anyways so guess not a big deal.

There's also the weird case where a user registers two BSP, with different tagging decorators. Since it's the same span though such tagging can't happen independently. So decorating to tag doesn't quite feel right and possibly should be forbidden if possible.

Filtering indeed we lose out but I wonder if it implies calling toSpanData before sending to BSP? Otherwise if only filtering on ReadableSpan, I think a Sampler decision of record but not sampled would be similar given the information available. Any examples of how to filter at span processor level?

[Oberon00]

Filtering indeed we lose out but I wonder if it implies calling toSpanData before sending to BSP?

This is a Java-specific issue, the spec just says that the span passed to OnStart/OnEnd must be readable.

I think a Sampler decision of record but not sampled would be similar given the information available.

Indeed. The sampler should even have all the initial attributes available.

Any examples of how to filter at span processor level?

Tail-based sampling, i.e. filtering at OnEnd maybe?

To be honest, these introductory paragraphs in the spec for the SpanProcessor are quite confusing and feel rather vague to me.

[anuraaga]

This is a Java-specific issue, the spec just says that the span passed to OnStart/OnEnd must be readable.

Ah - I guess in Java doing the tail sampling would be quite unfortunate having to call toSpanData twice, both before and after BSP.

Guess this could be simpler if it was BatchSpanExporter instead of BatchSpanProcessor.

To be honest, these introductory paragraphs in the spec for the SpanProcessor are quite confusing and feel rather vague to me.

+1

[andrewhsu]

talked about this at the spec sig mtg today, marking as required for ga because need to verify if this is desirable to move on and if so, need to do this before ga release.

[tedsuo]

We should move very quickly if we are going to remove this.

It sounds like there are two separate questions:

• Is there a need for a BatchSpanProcessor interface to be exposed, for any reason? If it is not needed in Java, it is not needed in other languages either.
• Are there ways we can clean up initialization, so that these lower level concepts are not presented to users unless they need them? I agree that right now, in some cases you have to build too many things to initialize opentelemetry.

[bogdandrutu]

Also in java for example we have an alternative batch implementation that depends on Disruptor, and people would like to use that instead of the standard batch processor.

[anuraaga]

Talked through some ideas to make configuration simpler, for example replacing BatchSpanProcessor with BatchSpanExporter which implements SpanExporter, where the TracerProvider converts to SpanData, not an export-specific span exporter. But these are pretty big ideas and we can think about them post-GA, even if it means deprecating current types like BatchSpanProcessor, it's not a huge deal.

[andrewhsu]

from the spec sig mtg today, discussed this and moving this to after ga