Description
SpanProcessors are called directly on the critical path when a Span is started/ended. Some implementation may want to defer these events via an async framework. In java we do have a https://github.com/open-telemetry/opentelemetry-java/tree/master/sdk_contrib/async_processor which simply adds the events to a queue and process them later to avoid unnecessary work on the critical path.
The current design is a simple chain of SpanProcessor (SDK -> async_processor -> batch_exporter_processor) which works fine except that I do unnecessary work of queuing onStart events even though it is not needed by the batch_exporter_processor.
As possible solution I can have an option to the async_processor constructor that says queue onStart or not, but a more automatic solution of this would be better.
Proposal:
- Change SpanProcessor interface to have a
Requirementsoption
public interface SpanProcessor {
void onStart(ReadableSpan span);
void onEnd(ReadableSpan span);
Requirements getRequirements();
}
public enum Requirements {
ON_START_ONLY,
ON_END_ONLY,
ON_START_AND_ON_END;
}This way I can determine at runtime in the async_processor which events should be queued.
PS: Names are not very well thought but the idea I have it in my mind for quite a lot of time and I think it is a nice feature to have.
PSS: I think we should offer as part of an official contrib package an async_processor as the one provided in Java.