Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Load OTel SDK config from environment variables and system properties.… #1434

Conversation

cyrille-leclerc
Copy link
Member

Description:

Load OTel SDK config from environment variables and system properties.

Existing Issue(s):

Testing:

See added unit tests

Documentation:

< Describe the documentation added.
Please be sure to modify relevant existing documentation if needed. >

Outstanding items:

< Anything that these changes are intentionally missing
that will be needed or can be helpful in the future. >

AutoConfiguredOpenTelemetrySdk autoConfiguredOpenTelemetrySdk =
AutoConfiguredOpenTelemetrySdk.builder()
.setServiceClassLoader(getClass().getClassLoader())
.addPropertiesSupplier(() -> properties)
.addPropertiesCustomizer(configProperties -> {
// Change default of "otel.[traces,metrics,logs].exporter" from "otlp" to "none"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[minor] Could you elaborate a bit in a comment on why we need to override the default here ? For example, if I understand correctly when there is no endpoint configured then we assume the extension should silently skip exporting signals.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review Sylvain, please see updated comment

@trask
Copy link
Member

trask commented Sep 16, 2024

@cyrille-leclerc just a heads up looks like there's a failing test

@cyrille-leclerc
Copy link
Member Author

Thanks @trask , unit test fixed.

@trask
Copy link
Member

trask commented Sep 27, 2024

cc @kenfinnigan in case you have a chance to review

@cyrille-leclerc
Copy link
Member Author

@SylvainJuge could you by any chance review this PR?

@trask trask added this to the v1.40.0 milestone Oct 8, 2024
@cyrille-leclerc
Copy link
Member Author

Thanks @SylvainJuge , I'll improve ASAP

@cyrille-leclerc cyrille-leclerc requested a review from a team as a code owner October 18, 2024 10:48
@trask trask removed this from the v1.40.0 milestone Oct 18, 2024
System.setProperty("otel.service.name", "my-maven");
try {
testConfiguration("my-maven");
System.setProperty("otel.resource.attributes", "key1=val1,key2=val2");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be a bit better to not rely on global state (here in system properties) as we have to take care of the cleanup here.

What I think could be slightly better is to add an argument to the OpenTelemetrySdkService constructor to control which system properties are present or not if we can. While this slightly alters the design for test purpose it could be worth it here as it allows to get rid of any early cleanup or finally block. Also with such a change there can't be any side effect if system properties are set on the JVM that execute the tests which usually require us to ensure properties are not set in some cases.

The AutoConfiguredOpenTelemetrySdkBuilder.setConfigPropertiesCustomizer allows to override the config properties, but it's package-private so using AutoConfigureUtil.setConfigPropertiesCustomizer is needed. While it's an internal API doing this only for tests should be fine.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we postpone this improvement? I lack time to clean this up unfortunately.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we can definitely postpone that to later improvement. Just to keep it safe once this test class has executed adding an @AfterAll method to ensure there are no side effects on things that execute after.

System.clearProperty("otel.exporter.otlp.endpoint");
System.clearProperty("otel.service.name");
System.clearProperty("otel.resource.attributes");

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great suggestion. Please review below.

System.setProperty("otel.service.name", "my-maven");
try {
testConfiguration("my-maven");
System.setProperty("otel.resource.attributes", "key1=val1,key2=val2");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we can definitely postpone that to later improvement. Just to keep it safe once this test class has executed adding an @AfterAll method to ensure there are no side effects on things that execute after.

System.clearProperty("otel.exporter.otlp.endpoint");
System.clearProperty("otel.service.name");
System.clearProperty("otel.resource.attributes");

* <p>Inspired by {@link
* io.opentelemetry.sdk.autoconfigure.internal.AutoConfigureUtil#getConfig(AutoConfiguredOpenTelemetrySdk)}
*/
public static Resource getResource(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[minor] can you elaborate a bit why do we call this method and what it allows to do here ? In addition, is there a follow-up action to make this method publicly accessible in the SDK if there are other similar use-cases ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great catch. Comment added in he code of the OpenTelemetrySdkService. The use cases are:

  • Debugging & troubleshooting helping find traces if they are missing reporting the service.name and service.namespace
  • Testing: before this PR, we misconfigured the AutoConfigureOtlSdk and overwriting resource attributes through system properties or env vars failed.

In addition, is there a follow-up action to make this method publicly accessible in the SDK if there are other similar use-cases ?
Valid point, I didn't bring thes us cases to the Java SIG as I did in the past for other SDK config topics. We have the same debugging/troubleshooting use case in the Jenkins OTel plugin.

* <p>Inspired by {@link
* io.opentelemetry.sdk.autoconfigure.internal.AutoConfigureUtil#getConfig(AutoConfiguredOpenTelemetrySdk)}
*/
public static Resource getResource(
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great catch. Comment added in he code of the OpenTelemetrySdkService. The use cases are:

  • Debugging & troubleshooting helping find traces if they are missing reporting the service.name and service.namespace
  • Testing: before this PR, we misconfigured the AutoConfigureOtlSdk and overwriting resource attributes through system properties or env vars failed.

In addition, is there a follow-up action to make this method publicly accessible in the SDK if there are other similar use-cases ?
Valid point, I didn't bring thes us cases to the Java SIG as I did in the past for other SDK config topics. We have the same debugging/troubleshooting use case in the Jenkins OTel plugin.

// GlobalEventEmitterProvider.resetForTest();
// }
@AfterAll
static void afterAll() {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SylvainJuge please review

System.setProperty("otel.service.name", "my-maven");
try {
testConfiguration("my-maven");
System.setProperty("otel.resource.attributes", "key1=val1,key2=val2");
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great suggestion. Please review below.

Copy link
Contributor

@SylvainJuge SylvainJuge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just make sure to open an issue/PR to make the AutoConfiguredOpenTelemetrySdk#getResource publicly accessible, linking to this PR would help provide context why it's needed.

@cyrille-leclerc
Copy link
Member Author

@trask trask merged commit bfd7390 into open-telemetry:main Dec 9, 2024
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants