Make sure redis instrumentation follows semantic conventions

[srikanthccv]

No description provided.

[cBiscuitSurprise]

@srikanthccv I'd like to help with these. I'd like to start here with redis, then move on to other if possible.

[cBiscuitSurprise]

Notional Plan:

• update tests to check the semantic attributes exist
  • Case 1 (test_db_semantic_attributes_server):

    • Key	Value
      Span name	"GET"
      db.system	"redis"
      server.address	"localhost"
      server.port	6379
      network.transport	"tcp"
      network.type	"ipv4"
      db.statement	"GET ?"
      db.redis.database_index	0

  • Case 2 (test_db_semantic_attributes_socket):

    • Key	Value
      Span name	"GET"
      db.system	"redis"
      server.socket.address	"/tmp/redis.sock"
      network.transport	"Unix"
      db.statement	"GET ?"
      db.redis.database_index	0

• Update instrumentation implementation to pass the tests

[cBiscuitSurprise]

Current attributes:

    "attributes": {
        "db.statement": "GET ?",
        "db.system": "redis",
        "db.redis.database_index": 0,
        "net.peer.name": "localhost",
        "net.peer.port": 6379,
        "net.transport": "ip_tcp",
        "db.redis.args_length": 2
    },

[cBiscuitSurprise]

I created the tests, but found the following:

opentelemetry.semconv.trace doesn't have the following attributes:

1. server.address
2. server.port
3. server.socket.address
4. network.transport (has net.transport with similar values)
5. network.type

• I think we will want to update [opentelemetry-python] opentelemetry/semconv/trace/init.py with these new (?) values.

A couple issues that may be relavant (?):

• Change messaging related semantic convention attributes opentelemetry-python#3145
• Change net.* related semantic convention attributes opentelemetry-python#3144

[srikanthccv]

I assigned this to you. Please see open-telemetry/opentelemetry-python#3251 for updating the semconv.

[cBiscuitSurprise]

Thank you! Should this task (#1627) wait until we're aligned on semconv latest (which is currently 1.24.0)?

Just brainstorming: Is it possible to add a layer in opentelemetry.semconv like:

from opentelemetry.semconv import SemConv
semconv = SemConv(version="1.20.0");
semconv.span_attributes.SERVER_ADDRESS

It doesn't completely solve the coupling, but may help break up the PRs. You could simply have one relatively small CR to make the new version available for use, then incrementally update usage in all of the sub-packages in separate PRs. This could allow skipping sub-package updates if say 1.21.0, 1.22.0, etc. come along before all the sub-packages are updated. Then follow up by deprecating unused versions as all the usage is updated.

---

Edit: I'm just now realizing this library is versioned in lock-step, so nvm.

[cBiscuitSurprise]

@srikanthccv I created a PR for now it's pointing to the depended PR (the 1.20.0 change), but once that's merged I can open a real one on the main project.

Is this approach acceptable? Basically I added tests and then fixed the impl where things weren't quite right.