You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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}_ENABLED OTEL_RUBY_INSTRUMENTATION_${name}_CONFIG_OPTS
The text was updated successfully, but these errors were encountered:
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}_ENABLED
OTEL_RUBY_INSTRUMENTATION_${name}_CONFIG_OPTS
The text was updated successfully, but these errors were encountered: