-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redis -- service.instance.id #22044
Comments
Pinging code owners for receiver/redis: @dmitryax. See Adding Labels via Comments if you do not have permissions to add labels yourself. |
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 Pinging code owners: See Adding Labels via Comments if you do not have permissions to add labels yourself. |
@hughesjj Have you consider [run_id] Regarding the proposal how you would tackle the issue of having (duplicated) |
Checking the latest semantic conventions, it does seem redundant to set I could be convinced to set 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 |
Make sense, I didn't see they already were there.
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 |
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 Pinging code owners: See Adding Labels via Comments if you do not have permissions to add labels yourself. |
…ibutes (#26707) **Description:** <Describe what has changed.> Two new resource attributes have been added: `server.address` and `server.port`. This is change aligned with [semantic conventions](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.25.0/specification/semantic-conventions.md?plain=1#L30) and allows users identifying a particular redis server. **Link to tracking Issue:** #22044 **Testing:** <Describe what testing was performed and which tests were added.> ``` ❯ go test -race -timeout 300s -parallel 4 --tags="",integration --count 1 ./... ok github.com/open-telemetry/opentelemetry-collector-contrib/receiver/redisreceiver 6.179s ok github.com/open-telemetry/opentelemetry-collector-contrib/receiver/redisreceiver/internal/metadata 1.464s ``` * Added: new test to check error when the configuration endpoint is missing or invalid * Updated: integration test to check new resource attributes **Documentation:** <Describe the documentation added.> New attribute documentation was generated using `mdatagen` --------- Co-authored-by: Antoine Toulme <[email protected]>
…ibutes (open-telemetry#26707) **Description:** <Describe what has changed.> Two new resource attributes have been added: `server.address` and `server.port`. This is change aligned with [semantic conventions](https://github.com/open-telemetry/opentelemetry-specification/blob/v1.25.0/specification/semantic-conventions.md?plain=1#L30) and allows users identifying a particular redis server. **Link to tracking Issue:** open-telemetry#22044 **Testing:** <Describe what testing was performed and which tests were added.> ``` ❯ go test -race -timeout 300s -parallel 4 --tags="",integration --count 1 ./... ok github.com/open-telemetry/opentelemetry-collector-contrib/receiver/redisreceiver 6.179s ok github.com/open-telemetry/opentelemetry-collector-contrib/receiver/redisreceiver/internal/metadata 1.464s ``` * Added: new test to check error when the configuration endpoint is missing or invalid * Updated: integration test to check new resource attributes **Documentation:** <Describe the documentation added.> New attribute documentation was generated using `mdatagen` --------- Co-authored-by: Antoine Toulme <[email protected]>
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 withendpoint
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
The text was updated successfully, but these errors were encountered: