Add Support for OpenTelemetry Semantic Conventions in OpenTelemetryTraceEventListener

[agent-adam]

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:

1. 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"
  }
}

2. 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.

[jeandelavarene]

Hi @agent-adam, the span created by the OpenTelemetryTraceEventListener should be a child span of the one created by the agent. This may be a bug. @fmeheust?

[fmeheust]

Hi @agent-adam, the span created by the OpenTelemetryTraceEventListener should be a child span of the one created by the agent. This may be a bug. @fmeheust?

Hi @jeandelavarene it looks like the two spans should have a parent/child relationship. This can be due to the fact that we are closing the scope in the BEFORE event, maybe we should keep the scope open for the duration of the span. I will look into it.

Concerning the convention should we follow 1.29.0 (which at the moment has a status "Release candidate") or 1.24.0 ?