ObservationConvention for OpenTelemetry Semantic Conventions (Database)

[ttddyy]

Micrometer is going to support the stable portion of OpenTelemetry semantic conventions. (micrometer-metrics/micrometer#5794)

Provide the same for database parts by an ObservationConvention implementation.

[shakuzen]

The relevant database conventions are at https://opentelemetry.io/docs/specs/semconv/database/

[wimdeblauwe-volvo]

How concrete are the plans to support this? When using io.opentelemetry.instrumentation:opentelemetry-jdbc, I get a nicer span name of INSERT testdb.orders where I get dataSource: query with this library. (Which is also what #75 was about I think).

[ttddyy]

@wimdeblauwe-volvo Thanks for the nudge. I'll work on getting the OTEL convention moving forward.

[kdebski85]

Due to this issue I had to replace net.ttddyy.observation:datasource-micrometer-spring-boot (+micrometer-tracing-bridge-otel) with io.opentelemetry.instrumentation:opentelemetry-jdbc.

I use New Relic for gathering traces/metrics and with net.ttddyy.observation:datasource-micrometer-spring-boot it wasn't showing anything in Databases tab. Switching to io.opentelemetry.instrumentation:opentelemetry-jdbc solved the issue.

I debugged both libraries with io.opentelemetry:opentelemetry-exporter-logging-otlp to see spans' attributes.

I use Postgres DB and according to https://opentelemetry.io/docs/specs/semconv/database/postgresql/ :
db.system.name MUST be set to "postgresql" and SHOULD be provided at span creation time.

However, datasource-micrometer-spring-boot does not create such attribute.
opentelemetry-jdbc on the other hand creates attribute db.system (not db.system.name)

{
   "key": "db.system",
    "value": {
         "stringValue": "postgresql"
    }
},

With opentelemetry-jdbc, New Relic correctly displays it as Postgres query.
So, I think the lack of db.system (or db.system.name) is one of issues.

Here is a comparison of attributes for both libraries:

1. datasource-micrometer-spring-boot

{
  "key": "jdbc.datasource.driver",
  "value": {
    "stringValue": "org.postgresql.Driver"
  }
},
{
  "key": "jdbc.datasource.name",
  "value": {
    "stringValue": "...."
  }
},
{
  "key": "jdbc.datasource.pool",
  "value": {
    "stringValue": "HikariPool-1"
  }
},
{
  "key": "jdbc.query[0]",
  "value": {
    "stringValue": "SELECT ...."
  }
},
{
  "key": "peer.service",
  "value": {
    "stringValue": "..."
  }
}

2. opentelemetry-jdbc

{
  "key": "db.connection_string",
  "value": {
    "stringValue": "postgresql://localhost:5432"
  }
},
{
  "key": "db.name",
  "value": {
    "stringValue": "...."
  }
},
{
  "key": "db.operation",
  "value": {
    "stringValue": "SELECT"
  }
},
{
  "key": "db.statement",
  "value": {
    "stringValue": "SELECT ..."
  }
},
{
  "key": "db.system",
  "value": {
    "stringValue": "postgresql"
  }
},
{
  "key": "server.address",
  "value": {
    "stringValue": "localhost"
  }
},
{
  "key": "server.port",
  "value": {
    "intValue": "5432"
  }
}

[ttddyy]

I use Postgres DB and according to https://opentelemetry.io/docs/specs/semconv/database/postgresql/ :
db.system.name MUST be set to "postgresql" and SHOULD be provided at span creation time.

Yes, it is the OTEL semantic conventions spec, which is different from what datasource-micrometer provides.

So, I think the lack of db.system (or db.system.name) is one of issues.

If only this attribute is the issue in your backend, as a temporary workaround, you can use the approach described here:
#34 (comment)

Currently, I am developing an alternative QueryObservationConvention to support the Opentelemetry semantic conventions. Once that is in place, users can choose to use the spans that will have the attributes from the stable part of the spec.

[ttddyy]

I’ve made good progress on the OpenTelemetry semantic conventions support and created a new branch: otel-sem-conv-boot3. I’ll continue pushing updates as I clean things up, including some destructive operations like squashing and force-pushing, but you’re welcome to take a look in the meantime. The essentials are already working, though some cleanup is still needed.

In the change, I introduced a new module: datasource-micrometer-opentelemetry.
Adding this module will auto-configure the query convention to produce spans compatible with the semantic conventions.

The work is based on Boot 3 (1.x branch), but it’s mostly independent of Boot itself, so it should also work with Boot 4 (main branch). In fact, I originally developed it on main and just rebased it onto the Boot 3 branch without needing any changes.