Redis -- service.instance.id

[hughesjj]

Component(s)

No response

Is your feature request related to a problem? Please describe.

This captures the spirit of some long closed issues now that we have better guidance on semantic conventions for identifying an "instance" (db or otherwise)

Describe the solution you'd like

I'd like to use service.instance.id to be populated with endpoint from the collector configuration.

Describe alternatives you've considered

We could also add more information like the db_index to the instance id but I don't really see that as a different "instance", and that would live better as either another attribute at the resource or metrics level, but open to discussion.

Additional context

No response

[github-actions]

Pinging code owners for receiver/redis: @dmitryax. See Adding Labels via Comments if you do not have permissions to add labels yourself.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• receiver/redis: @dmitryax @hughesjj

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[gsanchezgavier]

@hughesjj Have you consider [run_id]
(https://redis.io/commands/info/#:~:text=run_id%3A%20Random%20value%20identifying%20the%20Redis%20server%20(to%20be%20used%20by%20Sentinel%20and%20Cluster))?
It looks like it identifies the instance but I see that it is being regenerated each restart so I'm a bit concerned that it could lead to confusion.

Regarding the proposal how you would tackle the issue of having (duplicated) localhost as the endpoint in the config in case the Redis instance being monitored is in the same Host as the Collector?

[hughesjj]

@gsanchezgavier

Random value identifying the Redis server (to be used by Sentinel and Cluster)

Checking the latest semantic conventions, it does seem redundant to set service.instance.id to endpoint:port or similar given endpoint and port are already required.

I could be convinced to set service.instance.id to the run_id. It's an existing problem with ephemeral instances such as lambda etc. If the user wants to explicitly tag a resource, they can always define it themselves in their receiver configuration via an attributes processor etc, which imho is a more consistent way.

Semantically, I would argue that "instance" means "instantiation". If you terminate + restart the application or hardware, you've birthed a new "instance".

So, provided it's consistent as expected, yes, I'm all for run_id, but let's double check possible implications.

[gsanchezgavier]

Checking the latest semantic conventions, it does seem redundant to set service.instance.id to endpoint:port or similar given endpoint and port are already required.

Make sense, I didn't see they already were there.

If the user wants to explicitly tag a resource, they can always define it themselves in their receiver configuration via an attributes processor etc, which imho is a more consistent way.

We (in NewRelic) are thinking of recommending this as a way to identify the Instance but it becomes a bit harder to set when you want to have more than one Redis Receiver in the config, since it requires creating different processors and assigning them to each receiver in different pipelines.

Regarding run_id as service.instance.id I fear that it could increase cardinality without providing much value rather than understanding if the Redis instance has been restarted, which perhaps could be solved with a restart count metric.