Add redis specification

[haboy52587]

Fixes #

Changes

Please provide a brief description of the changes here. Update the
CHANGELOG.md for non-trivial changes. If CHANGELOG.md is updated,
also be sure to update spec-compliance-matrix.md if necessary.

Related issues #

Related oteps #

[linux-foundation-easycla]

• ✅ login: reyang / name: Reiley Yang (fb87208)
• ❌ The commit (924b8fb, eae1fc7). This user is missing the User's ID, preventing the EasyCLA check. Consult GitHub Help to resolve.For further assistance with EasyCLA, please submit a support request ticket.

[reyang]

@haboy52587 thanks for your contribution!

Please refer to this PR #2458 where we've decided to focus on "what" do we get from the Instrument, rather than "how". In a nutshell, consider removing "Asynchronous" / "Synchronous".

[reyang]

Could this be called redis.replicas.connected? (given most oss projects are moving from master branch to main branch, I guess in the long run Redis would be inclined to avoid "slaves")

[reyang]

Suggested change

	# Semantic conventions for database metrics
	# Semantic conventions for Redis metrics

[reyang]

The overall direction looks good to me once https://github.com/open-telemetry/opentelemetry-specification/pull/2525/files#r866476318 is addressed.

I'm not Redis expert, it'll be great to get someone who is familiar with Redis (or even better, could we invite folks from the Redis community?). Not necessarily blocking given the status of the doc is Experimental.

[reyang]

@haboy52587 please update the CHANGELOG.

[reyang]

@haboy52587 please clear the CLA.

Actually, please clear the CLA first.

[tigrannajaryan]

@haboy52587 I commented your previous PR.

Still missing:

• Sign the CLA.
• Write a proper PR description.
• There are already Redis semantic conventions: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/database.md, anything new needs to align with existing.

[carlosalberto]

@tigrannajaryan Actually the existing ones are for traces, and this is for metrics.

Other than that, there are some metric that looks very Redis specific, e.g. redis.clients.max_output_buffer or redis.memory.lua. Adding this kind would make sense still?

[tigrannajaryan]

@tigrannajaryan Actually the existing ones are for traces, and this is for metrics.

Other than that, there are some metric that looks very Redis specific, e.g. redis.clients.max_output_buffer or redis.memory.lua. Adding this kind would make sense still?

We use db.redis. prefix for Redis traces. I think we should do the same for metrics.

[carlosalberto]

I think we should do the same for metrics.

Oh, yes, let's definitely go with the same prefix.

[reyang]

I think we should do the same for metrics.

Oh, yes, let's definitely go with the same prefix.

Or maybe we should remove db. from Redis semantic convention (why is Redis considered db?). #2485 (comment)

[tigrannajaryan]

Or maybe we should remove db. from Redis semantic convention (why is Redis considered db?). #2485 (comment)

From https://github.com/redis/redis:

About
Redis is an in-memory database that persists on disk. The data model is key-value, but many different kind of values >are supported: Strings, Lists, Sets, Sorted Sets, Hashes, Streams, HyperLogLogs, Bitmaps.

Also from https://redis.com/:

Redis Enterprise is simply the best version of Redis, the most loved database in the world.

[carlosalberto]

Closing this one as the author won't be continuing with this - also @codeboten will take on this one.