Properties of sampler can not be transformed to YAML

[chenjazz]

The System property names is nested,can not be transformed to YAML . If we want to read from yaml file in the future versions,it will be a bug.

I think it should be added a name to the Properties,like this:

otel.traces.sampler.name
otel.traces.sampler.arg

Then it will be transformed:

otel:
   traces:
     exporter: otlp  
     sampler:
       name: parentbased_always_on
       arg:

Link: opentelemetry-java Issues

[arminru]

Thank you for raising this @chenjazz! The spec only defines environment variables and for these the name overlap is not an issue. Also, this part of the specification is considered stable already.

I suggest that for the Java SDK where System properties are used, otel.traces.sampler.name could just be used as the corresponding property for OTEL_TRACES_SAMPLER. Even though an exact match of the names would be preferable, there is no requirement to do so.
@open-telemetry/java-maintainers would this work for you?

[jkwatson]

Thank you for raising this @chenjazz! The spec only defines environment variables and for these the name overlap is not an issue. Also, this part of the specification is considered stable already.

I suggest that for the Java SDK where System properties are used, otel.traces.sampler.name could just be used as the corresponding property for OTEL_TRACES_SAMPLER. Even though an exact match of the names would be preferable, there is no requirement to do so. @open-telemetry/java-maintainers would this work for you?

No, I don't think this is a good idea, having the env vars drift from the system properties. They are intentionally precisely aligned today. I don't think we should change anything without the possible specification work to support a more comprehensive configuration-file format.

[arminru]

@jkwatson I see. When a more comprehensive configuration approach is designed, this will certainly be taken into consideration. The current naming guidelines for attributes already prohibit names that clash with namespaces and the same should then apply to config keys.

@jkwatson @chenjazz Is there currently a need for these system properties derived from the env vars to be expressed in a YAML format at this point or is this just a concern that it could break features in future?

[ocelotl]

I asked Claude to review this issue and Claude suggests it be closed with this explanation:

The concern was that env-var-derived sampler config keys (otel.traces.sampler / .arg) don't map cleanly to YAML. Maintainers (jkwatson, arminru) explicitly deferred any change to a future 'more comprehensive configuration-file format' rather than drifting sys-props from env vars. That future work is now the declarative/file configuration effort (open-telemetry/opentelemetry-configuration), whose YAML schema models the sampler as a structured object with name/args, satisfying the ask; the pre-config-work spec concern is no longer actionable here.

To guard against a mistaken suggestion, Claude then independently re-verified this conclusion:

Verified: maintainers (jkwatson/arminru) declined to drift sys-props from env vars and deferred to a future config-file format; that work now exists as opentelemetry-configuration, whose YAML schema models the sampler as a structured object (confirmed in examples/otel-sdk-config.yaml: sampler -> parent_based -> root -> always_on), independent of the flat env-var names, so the original spec-repo concern is no longer actionable.

Claude evaluated this issue with medium confidence that it can be closed.

Claude has classified this issue as obsolete.

The intention of this comment is to make it easier for a human being to review this issue before making a decision.

[svrnm]

Closing this issue, it was discussed, no conclusion found and stalled. If you think this topic should be discussed again, reopen or raise a new issue.