Skip to content

Allow JdbcTelemetry to rely on java opts #13870

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

Open
AlixBa opened this issue May 16, 2025 · 1 comment
Open

Allow JdbcTelemetry to rely on java opts #13870

AlixBa opened this issue May 16, 2025 · 1 comment
Labels
enhancement New feature or request needs triage New issue that requires triage

Comments

@AlixBa
Copy link
Contributor

AlixBa commented May 16, 2025

Is your feature request related to a problem? Please describe.

// opts
-Dotel.instrumentation.jdbc.experimental.capture-query-parameters=true

// and somewhere in the code
JdbcTelemetry.create(otel).wrap(ds)

I think people will expect the opt to be enabled and get data in my spans. But as per the current implementation, JdbcTelemetryBuilder only relies on properties set explicitly such as builder.setCaptureQueryParameters(true).

I see that in OpenTelemetryDataSource there is a deprecated constructor relying on JdbcInstrumenterFactory which allows construction based on the opts. It has been deprecated with introduction of JdbcTelemetry andJdbcTelemetryBuilder.

Describe the solution you'd like

Would it be possible to provide something like JdbcTelemetry.autoConfigured(otel) for this use case or is it something that has been not allowed on purpose?

Describe alternatives you've considered

No response

Additional context

I'd be happy to implement it as soon as we have a solution!

@AlixBa AlixBa added enhancement New feature or request needs triage New issue that requires triage labels May 16, 2025
@laurit
Copy link
Contributor

laurit commented May 19, 2025

Would it be possible to provide something like JdbcTelemetry.autoConfigured(otel) for this use case or is it something that has been not allowed on purpose?

If something like this were to be implemented it would need to be consistently implemented for all of the library instrumentations. It is unlikely that just using system properties and environment variables is going to cut it as someone is bound to ask for providing configuration through spring properties etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request needs triage New issue that requires triage
Projects
None yet
Development

No branches or pull requests

2 participants