Use azure.vm.name attribute in both Azure detector and SFx hostid logic #12908
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description: The Azure resource detector writes the "name" value from the Azure metadata API to the
host.name
attribute of the current resource. The problem with this is that the thehost.name
attribute is also written to by the system detector, and the Azure detector may not have precedence, in which case the Azure metadata name value won't be available downstream. The signalfx exporter requires the name from the Azure metadata API to operate (and other components may as require it as well at some point) so this change both saves this value to a new resource attribute key,azure.vm.name
, (in addition to continuing to write it to thehost.name
attribute) and reads from this new attribute in the signalfx exporter.Link to tracking Issue: #12779
Testing: Unit tests added. Manual testing was performed on Azure.
Documentation: Field added to readme