DB semconv: db-specific connection metrics or generic ones?

[lmolkova]

We currently have some connection-level metrics defined for databases: https://github.com/open-telemetry/semantic-conventions/blob/main/docs/database/database-metrics.md

At the same time, connection/pool metrics would be the same for different technologies. See https://github.com/open-telemetry/semantic-conventions/issues/454 for more details.

Proposal:

• short-term: exclude db connection-level metrics from DB stabilization scope and keep them experimental
• longer-term: introduce generic metrics and remove db-specific ones

[trask]

@open-telemetry/java-instrumentation-approvers we have a lot of database connection instrumentations in Java, any thoughts?

[trask]

it could still be useful to have different metric names, it feels a bit similar to how we have different metrics for http/rpc/db request durations

do you think there's a use case for aggregating across both database connection pools and other kinds of pools?

[lmolkova]

Note: this issue is not about pools, but about connections.

Let's assume we evolve semconv to the state that we have :

• socket connection metrics
• http connection metrics
• amqp connection metrics
• db connection metrics
• rpc connection metrics
• ...

All of them would have somewhat different set of attributes. Would it be a good user experience?

Essentially they are all socket connections. If socket-level is instrumented, we'll have duplication.

Now back to the connection pools: would it be a good experience if each of pool metrics would have custom *.connection.state attribute with idle|active|used values?

While DB or HTTP connection pool may have extra metrics specific to that pool, they can still share metrics for the underlying connections.

[pyohannes]

do you think there's a use case for aggregating across both database connection pools and other kinds of pools?

I assume this is less a question of aggregating (which one can also do across different metrics), but more about consistency?

Given that there isn't much experience with connection level metrics (across semantic convention areas), I'd recommend to exclude those from initial stability. I don't think those metrics would be a "must" for initial stable DB semantic conventions.

I think that quite some amount of research and prototyping will be required to come to a well-founded decision.

[trask]

short-term: exclude db connection-level metrics from DB stabilization scope and keep them experimental

👍