open-telemetry / open-telemetry/opentelemetry-python-contrib

opentelemetry-instrumentation: read declarative configuration from ConfigProvider in BaseInstrumentor

Open
#5,027 1 comment 0 reactions 0 assignees View on GitHub

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:

  1. Reads the global ConfigProvider and navigates to this instrumentor's node under the instrumentation configuration.
  2. Builds the config dataclass declared by the class attribute added in https://github.com/open-telemetry/opentelemetry-python-contrib/pull/4766, applying type coercion.
  3. Raises on an unknown key instead of ignoring it, so a typo in the configuration file is reported to the user.
  4. Does nothing when no ConfigProvider is 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:

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.