opentelemetry-sdk: Implement tracer configurator #4861
Conversation
Implement part of the tracing SDK spec to configure the tracers https://opentelemetry.io/docs/specs/otel/trace/sdk/#configuration At the moment this adds helper in order to enable or disable a tracer after it has been created. The spec in is development so attributes, helpers and classes are prefixed with underscore. TODO: hook into sdk configuration
| id_generator: Optional[IdGenerator] = None, | ||
| span_limits: Optional[SpanLimits] = None, | ||
| *, | ||
| _tracer_configurator: Optional[_TracerConfiguratorT] = None, |
There was a problem hiding this comment.
This was the java thing I was mentioning: https://github.com/open-telemetry/opentelemetry-java/tree/main/api/incubator
I agree it might be overkill for this feature though.
There was a problem hiding this comment.
Yeah, I'm not sure how this maps into Python. The implementation I've added here with adding a new kwarg prefixed with the underscore is more or less the same it would be the concrete implementation when using overload to provide the one with only stable parameters.
|
|
||
|
|
||
| _TracerConfiguratorT = Callable[[InstrumentationScope], _TracerConfig] | ||
| _TracerConfiguratorRulesPredicateT = Callable[ |
There was a problem hiding this comment.
I guess a callable is not very declarative config friendly
| return environ.get(OTEL_PYTHON_ID_GENERATOR, _DEFAULT_ID_GENERATOR) | ||
|
|
||
|
|
||
| def _get_tracer_configurator() -> str | None: |
There was a problem hiding this comment.
I've added the configuration via env var to match what we are doing with the others TraceProvider parameters, since this is in development I can drop it. For my use case I can just use _OTelSDKConfigurator._configure.
| set_status_on_exception: bool = True, | ||
| ) -> trace_api.Span: | ||
| if not self._is_enabled: | ||
| return INVALID_SPAN |
There was a problem hiding this comment.
The key behavior of tracer configurator is:
If a Tracer is disabled, it MUST behave equivalently to a No-op Tracer.".
Where the behavior of a noop tracer is:
However, there is one important exception to this general rule, and that is related to propagation of a SpanContext: The API MUST return a non-recording Span with the SpanContext in the parent Context (whether explicitly given or implicit current). If the Span in the parent Context is already non-recording, it SHOULD be returned directly without instantiating a new Span. If the parent Context contains no Span, an empty non-recording Span MUST be returned instead (i.e., having a SpanContext with all-zero Span and Trace IDs, empty Tracestate, and unsampled TraceFlags). This means that a SpanContext that has been provided by a configured Propagator will be propagated through to any child span and ultimately also Inject, but that no new SpanContexts will be created.
Does INVALID_SPAN here follow this behavior? In the java implementation, we use the noop tracer when a tracer is disabled, which returns a non-recording span to propagator the span context here.
There was a problem hiding this comment.
The NoOpTracer in Python has the very same behavior of returning INVALID_SPAN, that is a NonRecordingSpan:
INVALID_SPAN = NonRecordingSpan(INVALID_SPAN_CONTEXT)
That may not match what the spec says though. Thanks for the review.
3 participants
Description
Implement part of the tracing SDK spec to configure the tracers https://opentelemetry.io/docs/specs/otel/trace/sdk/#configuration
At the moment this adds helper in order to enable or disable a tracer after it has been created.
The spec in is development so attributes, helpers and classes are prefixed with underscore.
TODO:
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Does This PR Require a Contrib Repo Change?
Checklist: