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.
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
OpenTelemetryTraceEventListenerextension for Oracle JDBC and love the additional insights it provides for database calls, such asSQL IDandConnection 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:
{ "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" } }{ "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.jdbcbut I would need spans fromOpenTelemetryTraceEventListenerto follow the OpenTelemetry semantic conventions for database spans so users don't lose compatibility with existing tools and dashboards that expect the semantic conventions.