Description
Proposal:
Would the team be open to adding support for OpenTelemetry semantic conventions in OpenTelemetryTraceEventListener
? This could be implemented behind a feature flag, allowing users to toggle between the existing format and semantic conventions. I’d be happy to contribute this feature if there’s interest!
Note: long term we could even add an Oracle semantic conventions that folks can follow similar to what HBASE have done https://opentelemetry.io/docs/specs/semconv/database/hbase/
Context:
I’m currently using the OpenTelemetryTraceEventListener
extension for Oracle JDBC and love the additional insights it provides for database calls, such as SQL ID
and Connection ID
. However, when using this listener alongside OpenTelemetry’s auto-instrumentation library (io.opentelemetry.jdbc), I noticed that both create spans for the same database operations, leading to duplicate spans.
Example:
- Span created by io.opentelemetry.jdbc:
{
"traceId": "1cc26959cfeb014b6670637c641b1d3a",
"parentId": "dceb8e41121dd4b8",
"id": "70c2064652dea30b",
"kind": "CLIENT",
"name": "select orclcdb?oracle.jdbc.provider.traceeventlistener=open-telemetry-trace-event-listener-provider.dual",
"tags": {
"db.connection_string": "oracle:thin://oracle:1521",
"db.name": "orclcdb",
"db.system": "oracle",
"db.statement": "SELECT SYSDATE FROM DUAL",
"otel.library.name": "io.opentelemetry.jdbc"
}
}
- Span created by OpenTelemetryTraceEventListener:
{
"traceId": "420731d9ca3ffc9c20fbbdd227518db5",
"parentId": "5675099975433a9e",
"id": "1997042cb902f569",
"kind": "SERVER",
"name": "execute query",
"tags": {
"Actual SQL Text": "SELECT SYSDATE FROM DUAL",
"Connection ID": "X6DmEBCvQ06h3n0oq5U61g==",
"Database Operation": "Execute query",
"Database Tenant": "ORCLCDB",
"Database User": "SYSTEM",
"SQL ID": "c749bc43qqfz3",
"otel.library.name": "oracle.jdbc.provider.opentelemetry.OpenTelemetryTraceEventListener"
}
}
Ideally I would turn off the instrumentation from io.opentelemetry.jdbc
but I would need spans from OpenTelemetryTraceEventListener
to follow the OpenTelemetry semantic conventions for database spans so users don't lose compatibility with existing tools and dashboards that expect the semantic conventions.