Open dineshg13 opened 1 year ago
Right now we don't sanitize static queries because it would require parsing the SQL itself. Queries with parameters are properly sanitized because we know what they are. The only way to solve this would be to disable collecting ALL static queries by default and making them opt-in.
Also note that the semconv is a recommendation, not a requirement in this case.
I think we should engage with the semconv group on what we should do in this case. I think its unlikely that they expect SDKs to parse SQL statements, but I also don't know if they intended to disable collection of static queries.
@dyladan That make sense. I found similar issue with Python SDK https://github.com/open-telemetry/opentelemetry-python-contrib/issues/2003 . While Java sdk is sanitizing static queries. we Should address the inconsistencies across languages.
There are other instrumentations moving to an opt-in approach. In this PR the intent is to let the user provide a serializer
for the statement defaulting to a noop which does not serialize at all
https://github.com/open-telemetry/opentelemetry-js-contrib/pull/1748
Is there any easy workaround that allows us to alter or omit the db.statement
attribute somehow?
The only option I've found is to run an instance of attributesprocessor
, but that requires deploying a whole separate process with a different language runtime, which I don't have bandwidth for. So I'm just omitting the Postgres instrumentation from my app, regrettably.
What version of OpenTelemetry are you using?
My package.json
What version of Node are you using?
v20.6.1
What did you do?
When we use opentelemetry-instrument to automatically instrument a express app connected to postgres database, we notice that it doesn't sanitize queries with constant parameters, even though it collects db.statement by default. It goes against OTel semantic conventions .
What did you expect to see?
I expect to see
db.statement
sanitized. But am seeing below trace for static queries (/select
endpoint in below code). Sanitization works well for queries with params (/users/John) in below code.What did you see instead?
Additional context
Code