db|messaging|*.system describes the client library but not necessarily the underlying system

[lmolkova]

Usually client library is specific to a certain DB/broker/etc, but it's also common to support non-native libs/backends. Examples:

• Azure Event Hubs broker supports Kafka client libraries
• Azure CosmosDB can be used with MongoDB libs
• Several LLM solutions provide OpenAI-compatible REST APIs (1, 2, 3) and are used via OpenAI SDKs

So *.system might not be the perfect word since the attribute value describes the client lib only.
Keeping system might also be good enough, but we need to clarify the attribute definition.

[pyohannes]

The *.system attributes describes the system that the client library is a part of (for example if a span is created by JMS this should result in messaging.system=jms, if the underlying Kafka library creates a span, this should be messaging.system=kafka).

[pyohannes]

One other important point worth mentioning here is, that the system specified in e. g. messaging.system serves as a reference frame for other messaging.* attributes.

For example, if I'm using RabbitMQ via MassTransit in .NET, then for telemetry that has messaging.system=rabbitmq set, the value in messaging.message.id should be the RabbitMQ message id. For telemetry that has messaging.system=masstransit set, the value in messaging.message.id should be the MassTransit message id (which differs from the RabbitMQ message id).

[trask]

Keeping system might also be good enough

👍 (mostly because I can't think of something better though)

we need to clarify the attribute definition

👍

[jack-berg]

So *.system might not be the perfect word since the attribute value describes the client lib only.

It would be a shame if db.system was a descriptor of the client library and not the target system, since we already capture information about the client library in instrumentation scope.

[trask]

maybe it's more like a descriptor for the client protocol?

[lmolkova]

I'd say *.system describes the client library understanding of what it communicates with.

I also don't think there is a duplication between instrumentation scope name and system. E.g. lettuce does not adequately describe that telemetry conforms to databse semconv with redis extension.

[trask]

I also don't think there is a duplication between instrumentation scope name and system. E.g. lettuce does not adequately describe that telemetry conforms to databse semconv with redis extension.

👍