How do you generate OpenTelemetry traces for your queries?

[gitmalong]

Are there any solutions in place to easily generate traces that follow the otel db convention to make traces include the sql query?

Convention: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/database/

What I found so far:

• Abandoned PR to integrate tracing Initial work to switch to tracing #2185
• rust-opentelemetry-auto-span macro which can trace the plain query but does not follow otel conventions https://github.com/hinohi/rust-opentelemetry-auto-span

[miikka]

We're having the same issue. It seems to me the best option would be to finish the work on #2177 and add tracing spans whose attributes conform to OTel semantic conventions.

[syphar]

I had the same question, and was wondering how detailed they would have to be (we're using sentry, I need to check if the sentry-tracing span mapping would also be fine to recognize the OTEL db spans).

I imagine that it could be quite simple to add a span (tracing and/or sentry::Span) to sqlx-core::logger::QueryLogger. Though I would need to check when that object is created & dropped.

[rafiwicht]

I have the same need. I have some time to implement it, but I think it needs some refactoring. Here are the open issues I see:

• The logger configuration requires a Level instead of a Level. I personally find that quite odd and I couldn't find out, why this decision was made. I would change that.
• I need to add more functions to get all the information, required by the OpenTelemetry conventions.
• I will rewrite the attributes for the standard logs, to be compatible with the Opentelemetry conventions.

My plan is the following:

• I extend the QueryLogger with the span. I think it's a good idea to reuse it, because logs and spans use similar fields.
• I update the LogSettings to enable/disable the log and span functionality independently. I switch from LevelFilter to Level.
• I try to add some tests for QueryLogger with and without spans.

Due to this changes, it will no be backwards compatible. I would appreciate some feedback on my idea, before I start implementing it. Do you see any pitfalls or other problems?