Specify configuration mechanism for native instrumentations #3535
Labels
sig-issue
A specific SIG should look into this before discussing at the spec
spec:miscellaneous
For issues that don't match any other spec label
Comments
estolfo
added
the
spec:miscellaneous
6 tasks
austinlparker
added
the
sig-issue
github-project-automation
bot
moved this from In Progress
to Done
in Declarative Configuration Stability
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this issue
Oct 31, 2024
Resolves open-telemetry#3535. This introduces an API component to file configuration, which has been limited to SDK (i.e. end user facing) up until this point. The configuration model recently added the first surface area related to instrumentation configuration properties in open-telemetry/opentelemetry-configuration#91. The API proposed in this PR is collectively called the "Instrumentation config API", and provides a mechanism for instrumentation libraries to participate in file configuration and read relevant properties during initialization. The intent is for both OpenTelemetry-authored and native instrumentation alike to be able to be configured by users in a standard way. New API surface area is necessary to accomplish this to avoid instrumentation libraries from needing to take a dependency on SDK artifacts. The following summarizes the additions: - Introduce ConfigProvider, the instrumentation config API analog of TracerProvider, MeterProvider, LoggerProvider. This is the entry point to the API. - Define "Get instrumentation config" operation for ConfigProvider. This returns something called ConfigProperties, which is a programmatic representation of a YAML mapping node. The ConfigProperties returned by "Get instrumentation config" represents the [`.instrumentation`](https://github.com/open-telemetry/opentelemetry-configuration/blob/670901762dd5cce1eecee423b8660e69f71ef4be/examples/kitchen-sink.yaml#L438-L439) node defined in a config file. - Rebrand "file configuration" to "declarative configuration". This expresses the intent without coupling to the file representation, which although will be the most popular way to consume these features is just one possible way to represent the configuration model and use these tools. - Break out dedicated `api.md`, `data-model.md`, and `sdk.md` files for respective API, data model, and SDK portions of declarative configuration. This aligns with other portions of the spec. The separation should improve clarity regarding what should and should not be exposed in the API. I've prototyped this new API in `opentelemetry-java` here: open-telemetry/opentelemetry-java#6549 cc @open-telemetry/configuration-maintainers, @open-telemetry/specs-semconv-maintainers
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Having Open Telemetry instrumentation natively in libraries has the advantage of keeping ownership of the instrumentation with the library authors; it's a more sustainable way of maintaining instrumentations and is preferable to auto-instrumentations contributed to the language OTel projects.
With that said, there is no specified mechanism for defining and reading configuration for native instrumentations. This issue is meant to propose writing one.
As we discussed in the Specification SIG on 23 May, this may be a discussion for the Configuration SIG and we'd like to pull in opinions from language groups on current conventions.
For example, environment variables are used in Ruby OTel native instrumentations with the formats:
OTEL_RUBY_INSTRUMENTATION_${name}_ENABLEDOTEL_RUBY_INSTRUMENTATION_${name}_CONFIG_OPTSThe text was updated successfully, but these errors were encountered: