Does the traceparent header actually reaches the database servers (mongodb, mysql, postgres)?

[tomargovind]

If the application is instrumented with opentelemetry auto instrumentation (specifically @opentelemetry/auto-instrumentations-node) and the application makes outgoing database requests (mongodb, mysql, postgres), does the traceparent header actually reaches the database servers or just traces the operations at the application layer?

My application written in nodeJS is instrumented with @opentelemetry/auto-instrumentations-node. I tried looking up the traceparent header in the database packets using Wireshark, tcpdump, and database logs, but, I couldn't find it. Although, in the case of RabbitMQ or HTTP calls, I can clearly see the traceparent header inside the AMQP protocol headers and HTTP headers. So, for databases, does the traceparent actually propagate to the database servers or only limit working for the operations at the application layer?

[Flarna]

In general not.
Reason is that the protocols used to communicate with the database have no room to add something like HTTP headers.
For SQL there is SQL commenter which adds them as SQL comment but not sure if it is used by any existing instrumentation.
There are also databases which are accessed via HTTP where HTTP headers are added as usual.

including the W3C tracecontext makes only sense if the database itself picks it up and continues the trace. Not sure if there are any databases which actually create spans.

[tomargovind]

Hey @Flarna, Thanks for responding. I got your point and was able to see the traceparent in the query itself in the DB logs using SQL commenter by enabling addSqlCommenterCommentToQueries in @opentelemetry/instrumentation-pg in case of postgres. But, I did not see similar flag in other databases's instrumentations. Do you have any idea about this?
Also, Is there something similar to SQL commenter for nosql databases like mongoDB?

[Flarna]

I guess noone found the time yet to include sqlcommenter for other SQL database client instrumentations. The number of persons working on them is limited and maybe noone had a usecase for this till now.

I'm not aware of anything like this in nosql databases. I guess this requires analysis of the protocols used by them if there is even a room for optional data not impacting the query functionality.
Besides that sending traceparent to a database is only helpful if the database itself actually uses it to continue the trace or at least logs it. So it might be even needed to add functionality for this in the database itself to get end2end value.