-
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
[processor/resourcedetectionprocessor] Expose Azure resource tags #32953
[processor/resourcedetectionprocessor] Expose Azure resource tags #32953
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution! We can't accept your contribution unless you sign the CLA
tags: | ||
- ^tag1$ | ||
- ^tag2$ | ||
- ^label.*$ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is just adding all tags acceptable in terms of performance and number? i.e. Do Azure instances typically have a lot of tags?
Asking because I would like to keep it simple: if you want to filter, you can do that in a different component in your pipeline like the transform processor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Azure supports a max of 50 tags per resource, how many are actually in use of course varies depending on people's use cases.
In terms of "cost", we essentially get the data for free since it is included in the resource's metadata query results, unlike on AWS which requires a secondary rest call to fetch the tag information. So we are only paying the cost of the regex matching.
When implementing this I decided to keep it aligned with how the AWS implementation was exposed to users. The thought there was if someone is in a multi-cloud environment having them both configured the same, makes it easier for them to be used but I am not glued to that implementation choice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the detailed reply! I agree it's valuable to be aligned with the AWS detector. I guess we can always add an 'add all of them' setting if needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're welcome. As for the all
setting. Yup! In the interim, if people wanted to do this it would just require an unrestrictive regex .*
And CLA is finally signed. There was a hiccup on our side.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Description:
Adds support to expose regex matched Azure resource tags as opentelemetry resource attributes.
Link to tracking Issue:
Testing:
Documentation: