open-telemetry / open-telemetry/opentelemetry-python-contrib
opentelemetry-instrumentation: read declarative configuration from ConfigProvider in BaseInstrumentor
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.1k
- Forks
- 1.1k
- Avg merge
- 4d 15h
- Merged PRs (30d)
- 16
Description
What problem do you want to solve?
Declarative configuration options currently reach an instrumentor by a push path. configure_instrumentation() in opentelemetry-sdk/src/opentelemetry/sdk/_configuration/instrumentation.py reads the instrumentation/development.python.<name> node, coerces the raw mapping, and calls instrument(**options). That was added in https://github.com/open-telemetry/opentelemetry-python/pull/5372.
The Instrumentation Configuration API specification expects the opposite direction: instrumentation libraries access ConfigProvider during initialization, either because it is passed to them or because they read it from a global. See https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/api.md.
This was raised by @xrmx in https://github.com/open-telemetry/opentelemetry-python-contrib/pull/4766#issuecomment-5356515506.
The push path has a second problem. It couples the config dataclass field names to the instrument() keyword argument names by string only. A mismatch is silent, so every instrumentor that adopts declarative configuration needs an end to end test to catch it. That does not scale across the instrumentation packages in this repository.
Describe the solution you'd like
Add a default hook on BaseInstrumentor in opentelemetry-instrumentation/src/opentelemetry/instrumentation/instrumentor.py that:
- Reads the global
ConfigProviderand navigates to this instrumentor's node under the instrumentation configuration. - Builds the config dataclass declared by the class attribute added in https://github.com/open-telemetry/opentelemetry-python-contrib/pull/4766, applying type coercion.
- Raises on an unknown key instead of ignoring it, so a typo in the configuration file is reported to the user.
- Does nothing when no
ConfigProvideris installed or when the node is absent.
An individual instrumentor keeps declaring only its dataclass, exactly as URLLib3Instrumentor does in PR 4766. No instrumentation package repeats the read or the validation.
Precedence rule: an option passed explicitly to instrument() by user code wins over the same option set in the configuration file.
Describe alternatives you've considered
Keep the push path and let the SDK do the read. It is already merged and it works. It puts instrumentation specific knowledge in the SDK, it contradicts the access pattern the specification states, and it can only carry values expressible as plain YAML.
Have each instrumentation package read ConfigProperties directly with get_string, get_bool and the other typed getters. This matches the specification, but those getters return None both for a missing key and for a type mismatch, so a typo or a wrong type in the configuration file is silently ignored. It also duplicates the read and validate code in every instrumentation package.
The proposed hook combines both: the read comes from ConfigProvider as the specification describes, and the declared dataclass supplies the schema that makes an invalid key an error.
Additional Context
Ordering, because this work spans two repositories:
- Depends on the
configurationclass attribute added in https://github.com/open-telemetry/opentelemetry-python-contrib/pull/4766. - Depends on
ConfigProviderandConfigPropertiesfrom https://github.com/open-telemetry/opentelemetry-python/pull/5486. - Must land before the SDK side removes its coercion branch, tracked in https://github.com/open-telemetry/opentelemetry-python/issues/5619.
If the SDK stopped coercing before instrumentors could read configuration themselves, configured options would be silently dropped. While both paths are active the precedence rule above keeps behavior unchanged, because the keyword argument the SDK passes wins over the value read from the provider.
Would you like to implement a fix?
Yes
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in opentelemetry-instrumentation/src/opentelemetry/instrumentation/instrumentor.py at BaseInstrumentor, then read the referenced ConfigProvider and ConfigProperties changes in the SDK. Check how URLLib3Instrumentor declares its configuration dataclass. Done means the hook reads the instrumentor node when available, coerces declared fields, rejects unknown keys, leaves missing providers or nodes unchanged, and preserves explicit instrument() options.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- observability
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100