Conversation
|
PS. opentelemetry-java-examples#227 how this code can be coupled with changes to the contrib RuleBasedRoutingSampler to be able to configure the otel java agent to drop spans matching a particular pattern (like health checks), which is a very popular feature request. |
| + " str_key2: str_value2\n" | ||
| + " int_key2: 3\n" | ||
| + " - str_key1: str_value1\n" | ||
| + " int_key1: 2"; |
There was a problem hiding this comment.
Check out this test for examples of how to use the API to read complex types defined in a configuration file.
Notably, I've added support for dot notation to allow existing system property / environment variable configuration to be translated to a hierarchical representation in YAML.
For example, the property otel.javaagent.debug would be represented in YAML with:
otel:
javaagent:
debug: true
And you could access it using configProperties.getBoolean("otel.javaagent.debug").
Codecov ReportAttention:
... and 2 files with indirect coverage changes 📢 Thoughts on this report? Let us know!. |
…y-java into extended-config-properties
brunobat
left a comment
There was a problem hiding this comment.
We need to clarify:
- Which properties will work in the file configuration but not as env. vars.
- We need to make sure all properties can be set through the properties supplier and that the file configuration can be ignored in that case.
| void configFile_ExtendedConfigProperties() { | ||
| ConfigProperties config = | ||
| DefaultConfigProperties.createFromMap( | ||
| Collections.singletonMap("OTEL_CONFIG_FILE", configFilePath.toString())); |
There was a problem hiding this comment.
We need to provide a way to deactivate OTEL_CONFIG_FILE config loading if the properties supplier is being used directly in the Autoconfiguration.
There was a problem hiding this comment.
This is unrelated to this PR. Its already possible to deactivate OTEL_CONFIG_FILE via property suppliers. See the source code for how OTEL_CONFIG_FILE is loaded. Its accessed via ConfigProperties.getString("otel.config.file") using a ConfigProperties instance that is resolved using all the property suppliers and customizers typical in autoconfigure.
There was a problem hiding this comment.
Yes, it is unrelated with the PR but is of the upmost importance and should be clarified. From what I can see in the code, if the file exists, the programatic interface to create the SDK is not available anymore. This is a big problem.
@brunobat That feedback is orthogonal to this PR. This PR is about allowing complex configuration to be accessible via an |
Yes but we need to clarify which of those extended configurations will be available to be configured with Env. Vars. |
|
Closing in favor of #6457. |
Replaces draft #5873.
@open-telemetry/java-instrumentation-maintainers in the 9/21 Java SIG meeting I brought up bringing the file configuration prototype into the java agent, and received feedback that it will be important to specify other java agent properties besides the SDK in a configuration. Examples include accessing jmx configuration, and other standard properties like
otel.javaagent.debug=true.This PR extends file configuration tooling to include access to configuration not part of the configuration schema. Summary:
OTEL_CONFIG_FILEto the file pathOTEL_CONFIG_FILEis set and thatopentelemetry-sdk-extension-incubatoris on the classpath, and:OpenTelemetryConfigurationmodel to a genericExtendedConfigPropertiesrepresentation accessible viaAutoConfiguredOpenTelemetrySdk#getConfig()ExtendedConfigPropertiesimplementsConfigPropertiesand adds some additional methods for accessing nested complex configuration types (nested maps, and lists of maps)ExtendedConfigPropertiesand uses it for configurationSuppose you have a configuration file with contents like:
In java, you use the file to configure the SDK, as well as access the extended "javaagent" portion of the schema as follows: