OpenTelemetry instrumentation support?

[fdcastel]

Is there any interest in supporting OpenTelemetry instrumentation in the JDBC driver?

Reference: OpenTelemetry Database Spans Specification

I've previously worked on the .NET Provider in this PR (not yet merged, only used sporadically in private builds).

I'm now looking for suggestions or collaborators interested in discussing and aligning on implementation details (such as metric naming conventions, best practices for data collection, and other related topics).

[mrotteveel]

There already exists https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/jdbc/library/README.md which provides support (irrespective of the driver) by decorating any JDBC data source by one that adds metrics, or by using a driver that wraps connections from the "normal" JDBC driver.

What would be the benefit of adding something like this directly in Jaybird?

As an aside, you may also want to consider asking for input on firebird-general and firebird-java, to see if there is interest.

[fdcastel]

There already exists https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/jdbc/library/README.md which provides support (irrespective of the driver) by decorating any JDBC data source by one that adds metrics,

Interesting. I wasn’t aware of this.

I’m looking for practical, real-world use cases: which instrumentation signals are genuinely useful, and which ones are just noise.

What would be the benefit of adding something like this directly in Jaybird?

I sincerely don’t have a answer to this.

I’ll review your references more closely. That said, I’m just concerned that a generic solution may miss Firebird-specific details (transaction_id, attachment_id, etc.) which could be valuable for observability in some cases.