Rename db.operation to db.operation.name

[trask]

Changes

Renames db.operation to db.operation.name, to be more future proof and allow other attributes under the db.operation.* namespace in the future.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

Fixes #884

[pyohannes]

In messaging, we have messaging.operation, and I wonder if consistency is important here.

Do you have an example of what additional attributes might be expected under db.operation?

[lmolkova]

In messaging, we have messaging.operation, and I wonder if consistency is important here.

Do you have an example of what additional attributes might be expected under db.operation?

I think we might entertain the idea of db.operation.duration metric (and it might still be an open question for messaging metrics since operation list is an open set).

In case of databases, we have a precedent when CosmosDB records operation name (e.g. ReadItems) along with db.cosmosdb.operation_type (e.g. Read). We might want to generalize at some point.
If we translated it to messaging, we'd do something like messaging.operation.type = settle, messaging.operation.name = ack.

[lmolkova]

Also, graphql has operation.name and operation.type - https://github.com/open-telemetry/semantic-conventions/blob/main/docs/graphql/graphql-spans.md

I'm starting to understand why graphql used to be in the DB semconv - both try to describe QL

[pyohannes]

Discussed in the messaging workgroup: for messaging we'll take over what's adopted for databases, as we don't see any strong reasons to stick with messaging.operation as an attribute (and be inconsistent with database semantic conventions).

See the related issue #890.