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

ConfigurationFileLoader for OpenTelemetry manual instrumentation #5428

Open
tusharg1993 opened this issue May 5, 2023 · 4 comments
Open

Comments

@tusharg1993
Copy link

Is your feature request related to a problem? Please describe.
We are using OpenTelemetry javaagent for auto instrumentation and library for manual instrumentation. We are currently using otel.javaagent.configuration-file for java agent and load different configuration files for dev/prod environments and we pass the same using the environment variable.

We found that AutoConfiguredOpenTelemetrySdk also uses the same set of properties however, doesn't support loading configuration file like javaagent. I am wondering if there was ever a thought for enabling similar mechanism for manual instrumentation via autoconfiguration to accept a file as well. This way, we can reuse the same config file for both auto and manual instrumentation.

Describe the solution you'd like
Overall, idea was to implement something similar to ConfigurationFileLoader with a config like otel.autoconfiguration.configuration-file which gets used in AutoConfiguredOpenTelemetrySdkBuilder.getConfigs. We might want to have a different config values for java agent vs auto configured open telemetry objects since some usecases might want to have different customizations between auto vs manual instrumentation.

Describe alternatives you've considered
Nothing else really. Only thing I could probably do is add similar kind of code in my service to read a file and then pass AutoConfiguredOpenTelemetrySdkBuilder.propertiesSupplier()

Additional context
Covered above

@trask
Copy link
Member

trask commented May 5, 2023

I think this probably belongs in https://github.com/open-telemetry/opentelemetry-java, I will transfer it

I suspect this may be on hold until open-telemetry/opentelemetry-specification#2920

@trask trask transferred this issue from open-telemetry/opentelemetry-java-instrumentation May 5, 2023
@jack-berg
Copy link
Member

We're currently working on a file based configuration as described in this otep. Its a work in progress, but it will eventually include all the current environment configuration parameters and more options that we've been reluctant to define with flat environment variables.

@tusharg1993
Copy link
Author

Thanks for the pointers @trask @jack-berg!

@jack-berg If I am understanding the links correctly, the idea is precisely to allow hierarchical file based configurations for OpenTelemetry java SDK. Please confirm.

Also, are you looking to release this functionality in short term? We will be willing to give it a try. :)

@jack-berg
Copy link
Member

@jack-berg If I am understanding the links correctly, the idea is precisely to allow hierarchical file based configurations for OpenTelemetry java SDK. Please confirm.

I say highly structured configuration that better reflects the configurable surface area of the SDK than the current environment variable scheme.

Also, are you looking to release this functionality in short term?

Short-ish term. I've got a branch / PR where I've started the java implementation work in #5399. I think the limited factor will be agreeing on the actual configuration schema in opentelemetry-configuration. We're tracking the scope for MVP release here, so good to follow that project if you're interested.

Nothing else really. Only thing I could probably do is add similar kind of code in my service to read a file and then pass AutoConfiguredOpenTelemetrySdkBuilder.propertiesSupplier()

You could do this automatically (i.e. not have to invoke any code) by implementing the AutoConfigurationCustomizerProvider SPI and calling AutoCOnfigurationCustomizer#addPropertiesSupplier. Not a bad option if you need this now and are in a pinch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants