-
Notifications
You must be signed in to change notification settings - Fork 946
Added JDBC db.query.parameter span attributes #13719
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
base: main
Are you sure you want to change the base?
Added JDBC db.query.parameter span attributes #13719
Conversation
"SELECT 3", | ||
"SELECT ?", | ||
"SELECT 3, $1", | ||
"SELECT ?, $1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is the 3 sanitized in this case? (not related to this PR, just a regular question)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sanitizer replaces all literals with ?
. It does not distinguish where the literal appears or whether it just a random 3
or something sensitive like a password or a credit card number. The purpose of the sanitizer is to protect the users and apm vendors from accidentally sending sensitive information to the apm. Without having looked too much into your PR In my opinion it might be best if you first focus on prepared statements, if users wishes to see parameter values in sanitized queries they can disable the sanitizer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it might be best if you first focus on prepared statements, if users wishes to see parameter values in sanitized queries they can disable the sanitizer
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My concern with this PR is more to see parameters of the prepared statement itself. Currently, if I am doing things right, even with the sanitizer disabled, here is what I get from the library when I wrap with an OpenTelmetryDataSource in one of my app
SELECT pg_advisory_xact_lock(('x' || md5(?))::bit(64)::bigint)
where as my initial scala code (Scala + Doobie) looks like this
private def acquireLockByIdsNel(ids: NonEmptyList[String]): Query0[Unit] = {
val unique = ids.distinct.sorted
val frg = unique.map(id => fr"pg_advisory_xact_lock(('x' || md5($id))::bit(64)::bigint)")
val all = fragments.comma(frg)
(fr"SELECT" ++ all).queryWithLabel[Unit]("SELECT locks")
}
as this get translated into a PreparedStatement and having no clue about what is currently sent to the DB, I'd like db.(operation|query).parameter
to be set. Thing is, ?
is already used by the sanitizer. So in order to make things clear for the user, I have to(?) expose them as parameters.

Let me know if I misunderstood or going the wrong direction!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thing is, ? is already used by the sanitizer. So in order to make things clear for the user, I have to(?) expose them as parameters.
I wouldn't be too concerned with this. Firstly users can disable the sanitizer, as far as I can tell currently you basically attempt to undo what the sanitizer does by capturing the value. Secondly I'd expect that most queries that use prepared statements don't contain literals that the sanitizer removes. In your place I would start with capturing the parameters for prepared statements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then I think that this PR does exactly what I want!
I can remove the db.query.parameter for sanitized parameters from the query if that's an issue. But other than that, the PR captures the parameters from prepared statements
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd expect that most queries that use prepared statements don't contain literals that the sanitizer removes
ah, I think we should remove sanitization of prepared statement text in upcoming stable database semconv
this will also ensure the ?
placeholders line up with the db.query.parameter list
I've added this to our tracking issue #12608
@AlixBa check out very recent semconv change: open-telemetry/semantic-conventions#2093 |
hey @laurit |
...c/main/java/io/opentelemetry/instrumentation/api/incubator/config/internal/CommonConfig.java
Outdated
Show resolved
Hide resolved
...ava/io/opentelemetry/instrumentation/api/incubator/semconv/db/SqlClientAttributesGetter.java
Outdated
Show resolved
Hide resolved
instrumentation-api-incubator/src/main/jflex/SqlSanitizer.jflex
Outdated
Show resolved
Hide resolved
instrumentation/jdbc/README.md
Outdated
| System property | Type | Default | Description | | ||
|---------------------------------------------------------|---------|---------|----------------------------------------------------| | ||
| `otel.instrumentation.jdbc.statement-sanitizer.enabled` | Boolean | `true` | Enables the DB statement sanitization. | | ||
| `otel.instrumentation.jdbc.query-parameter.enabled` | Boolean | `false` | Enables the attribute db.query.parameter.<key> | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This table should be reformatted. The description of the flag needs to include a warning. I'll leave it to @trask to come up with the exact wording, probably something along the lines of WARNING: captured query parameters may contain sensitive information such as passwords, personally identifiable information or protected health info. Exposing such info may result in substantial fines and penalties or criminal liability. Consult your peers, superiors and a legal counsel before enabling this option
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's a good question, I've asked in the community repo
...n/java/io/opentelemetry/javaagent/instrumentation/jdbc/PreparedStatementInstrumentation.java
Outdated
Show resolved
Hide resolved
...ntelemetry/instrumentation/api/incubator/semconv/db/SqlClientAttributesExtractorBuilder.java
Outdated
Show resolved
Hide resolved
...ntelemetry/instrumentation/api/incubator/semconv/db/SqlClientAttributesExtractorBuilder.java
Outdated
Show resolved
Hide resolved
...opentelemetry/instrumentation/api/incubator/semconv/db/SqlClientAttributesExtractorTest.java
Outdated
Show resolved
Hide resolved
...opentelemetry/instrumentation/api/incubator/semconv/db/SqlClientAttributesExtractorTest.java
Outdated
Show resolved
Hide resolved
...n/java/io/opentelemetry/javaagent/instrumentation/jdbc/PreparedStatementInstrumentation.java
Outdated
Show resolved
Hide resolved
...in/java/io/opentelemetry/instrumentation/jdbc/internal/JdbcPreparedStatementStringifier.java
Outdated
Show resolved
Hide resolved
...in/java/io/opentelemetry/instrumentation/jdbc/internal/JdbcPreparedStatementStringifier.java
Outdated
Show resolved
Hide resolved
...in/java/io/opentelemetry/instrumentation/jdbc/internal/JdbcPreparedStatementStringifier.java
Outdated
Show resolved
Hide resolved
...in/java/io/opentelemetry/instrumentation/jdbc/internal/JdbcPreparedStatementStringifier.java
Outdated
Show resolved
Hide resolved
...in/java/io/opentelemetry/instrumentation/jdbc/internal/JdbcPreparedStatementStringifier.java
Outdated
Show resolved
Hide resolved
| System property | Type | Default | Description | | ||
|---------------------------------------------------------|---------|---------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | ||
| `otel.instrumentation.jdbc.statement-sanitizer.enabled` | Boolean | `true` | Enables the DB statement sanitization. | | ||
| `otel.instrumentation.jdbc.capture-query-parameters` | Boolean | `false` | Enables the attribute db.query.parameter.\<key\>.<br/><br/>WARNING: captured query parameters may contain sensitive information such as passwords, personally identifiable information or protected health info. Exposing such info may result in substantial fines and penalties or criminal liability. Consult your peers, superiors and a legal counsel before enabling this option.<br/><br/>This option will disable otel.instrumentation.jdbc.statement-sanitizer | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be added to metadata.yaml
Contribution for #7413
Not entirely sure about/need help/to finish
What does it do when opted-in?
Stringified types: