Database: clarify network attributes usage on common semconv

[lmolkova]

Changes

Addresses DB portion of #690:

• Removes network.transport|type attributes from general db semantic conventions.
• Clarifies when specific systems should set network.server.address|port and keeps them on the cassandra, redis and elasticsearch extensions

Based on the findings from Java instrumentation libraries, following instrumentations populate network attributes:

• cassandra
• redis (Redisson, jedis, lettuce, vertx, redis)
• elastic
• opensearch

See #698 (comment) for more details.

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.

[trask]

Based on the findings from Java instrumentation libraries, following instrumentations populate network attributes:

• cassandra
• redis (Redisson, jedis, lettuce, vertx, redis)
• elastic
• opensearch

do you think this is "because the instrumentation can", or because there is something about these databases that makes us include network.peer.address in addition to server.address?

what I'm trying to understand is what's the criteria for including (or excluding) network.peer.address in tech-specific database semconv

[lmolkova]

Based on the findings from Java instrumentation libraries, following instrumentations populate network attributes:

• cassandra
• redis (Redisson, jedis, lettuce, vertx, redis)
• elastic
• opensearch

do you think this is "because the instrumentation can", or because there is something about these databases that makes us include network.peer.address in addition to server.address?

what I'm trying to understand is what's the criteria for including (or excluding) network.peer.address in tech-specific database semconv

I can identify one good criteria - self-hosting (or hosting model where users configure/scale individual nodes).
Cassandra, Redis, Elastic and OpenSearch are in this camp (even though there are fully-managed offerings for some of them).

As a user who hosts cassandra, redis, elastic, etc clusters, I'm much more interested in which specific node this operation was performed on as it helps me detect issues with that specific node/my own infra, detect sharding/replication misconfiguration, etc.

If I use fully managed DB (DBaaS), specific node information is probably missing (even if I have an IP address, it's probably a public one from load balancer or NAT) and not actionable. Basic sharding/replication is handled by my vendor to a big extent and not visible to my application.

Update: mongoDB also supports self-hosted mode and might also be a candidate to have network.peer.* attributes

[lmolkova]

Update: based on the DB WG discussion on 3/8 the consensus is to keep network.peer.* in the general semconv with something like recommended: if applicable level