jdbc-observations / datasource-micrometer

Micrometer Observation API instrumentation and Spring Boot 3 Auto-Configuration for JDBC APIs
Apache License 2.0
50 stars 8 forks source link

Include db.system in the span for a jdbc query #34

Closed sunyongh closed 5 months ago

sunyongh commented 5 months ago

We are using the latest micrometer-tracing and datasource-micrometer-spring-boot to instrument the jdbc queries to a postgre sql db in a spring boot application. We can see the following 2 span attributes in the generated spans. Is it possible to include the attribute db.system into the span? This way, the backend code can identify it as a database client call for further processing.

{
  "peer.service": "dataSource",
  "jdbc.query[0]": "SELECT \"animal\".\"id\" AS \"id\", \"animal\".\"name\" AS \"name\" FROM \"animal\" WHERE \"animal\".\"name\" = ?"
}

Btw, db.system is a required attribute according to the semantic conventions of Database. https://github.com/open-telemetry/semantic-conventions/blob/main/docs/attributes-registry/db.md

key information in the pom.xml.

 <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>3.2.1</version>
        <relativePath/>
 </parent>

        <dependency>
            <groupId>io.micrometer</groupId>
            <artifactId>micrometer-tracing</artifactId>
            <version>1.2.2</version>
        </dependency>
        <dependency>
            <groupId>io.micrometer</groupId>
            <artifactId>micrometer-tracing-bridge-otel</artifactId>
            <version>1.2.2</version>
        </dependency>
        <dependency>
            <groupId>io.opentelemetry</groupId>
            <artifactId>opentelemetry-exporter-otlp</artifactId>
            <version>1.34.1</version>
        </dependency>
        <dependency>
            <groupId>net.ttddyy.observation</groupId>
            <artifactId>datasource-micrometer-spring-boot</artifactId>
            <version>1.0.3</version>
        </dependency>
ttddyy commented 5 months ago

You can utilize the datasource name to distinguish the span related to each datasource. The name is determined by the DataSourceNameResolver and the default implementation is DefaultDataSourceNameResolver.

The resolved name is mapped to the setRemoteServiceName in the micrometer span. In OtelSpanBuilder, it corresponds to the peer.service attribute.

You can implement your own DataSourceNameResolver or ObservationFilter to add tags you want to add to the spans. Let me know if this doesn't satisfy your usecase.

Btw, db.system is a required attribute according to the semantic conventions of Database. https://github.com/open-telemetry/semantic-conventions/blob/main/docs/attributes-registry/db.md

Yes, it is, for otel instrumentation, but it is not for non otel instrumentations. I'm not so keen on adding the db specific detection logic and maintain the list of db identifiers.

liurui-1 commented 5 months ago

@ttddyy Yes, it is not a problem of micrometer but it is a problem of micrometer-tracing-bridge-otel which targets to OTel users. Can micrometer-tracing-bridge-otel adds the required OTel resource attribute?

ttddyy commented 5 months ago

You can provide your own ObservationConvention and/or ObservationFilter to propagate tags(attributes) to the observations/spans.

For example, something like this:

public class MyObservationFilter implements ObservationFilter {
    @Override
    public Context map(Context context) {
        if (!(context instanceof DataSourceBaseContext)) {
            return context;
        }
        context.addLowCardinalityKeyValue(KeyValue.of("db.system", "MyDB"));
        return context;
    }
}

micrometer-tracing-bridge-otel is just a tracer implementation. So, I don't think it is required to put any otel semantic convention there.