Where should technology-specific (non-instrumentation) OTEL configuration elements be located?

[ysolomchenko]

There are several technology-specific environment variables (e.g., OTEL_DOTNET_AUTO_*, OTEL_JAVAAGENT_*) that are not directly related to instrumentation but are more general runtime or SDK-related configuration options.
Examples include:

• OTEL_DOTNET_AUTO_FAIL_FAST_ENABLED
• OTEL_DOTNET_AUTO_FLUSH_ON_UNHANDLEDEXCEPTION
• OTEL_DOTNET_AUTO_PLUGINS

These variables currently don’t have a clearly defined place in the OTEL configuration specification.

---

Question

Where should these technology-specific general settings be placed in the configuration structure?

Proposal 1 - New dedicated node (Best option on my opinion)

Introduce a new technology-specific configuration node to store these general settings.

technology_specific:
  dotnet:
    plugins: some.plugin
    fail_fast: true
    flush_on_unhandledexception: true

Pros:

• Clear separation between instrumentation and general technology-specific configuration.
• Scales well across multiple SDKs (e.g., dotnet, java, python, etc.).
• Maintains a clean root structure.

Cons:

• Adds one additional configuration layer.
• Requires specification updates and implementation changes.

Proposal 2 - Root-level placement

Place such variables directly under the root of the configuration file.

fail_fast: true
flush_on_unhandledexception: true
plugins: some.plugin

Pros:

• Clear and direct access to general runtime settings.
• Easier to read and maintain for each language.

Cons:

• The root may become cluttered and inconsistent across languages.
• Harder to maintain a unified schema across technologies.

Proposal 3 - Under instrumentation/development

Use the existing instrumentation/development: node, as currently done in some Java configurations.

instrumentation/development:
  dotnet:
    plugins: some.plugin
    fail_fast: true
    flush_on_unhandledexception: true

Pros:

• Keeps technology-specific configuration grouped under a known section.

Cons:

• Semantically unclear - these settings are not related to instrumentation itself.
• Overloads the meaning of the instrumentation/development node.

---

Additional Clarification

Could we please clarify the intended purpose of the instrumentation/development: node in the specification?

Currently, it seems to be used inconsistently across technologies, especially in Java, where it includes both instrumentation and non-instrumentation-related settings.