[processor/resourcedetection/internal/azure] HostName incorrectly set for VMs in Virtual Machine Scale Sets (VMSS) #43959
Description
Component(s)
processor/resourcedetection
What happened?
Description
I use Virtual Machine Scale Sets in Azure for traditional Virtual Machines as well as Azure Kubernetes Service.
In both these scenarios, I have noticed that the Resource Attribute host.name is incorrectly being set.
After reviewing the code here I noticed that compute.name is being used for both host.name and azure.vm.name resource attributes.
The value is correct for azure.vm.name but it seems incorrect for host.name.
When querying the Instance Metadata Service (IMDS) from one of these machines, it seems more appropriate for the host.name value to come from IMDS' compute.osProfile.computerName.
I have a VMSS named aks-system-36934070-vmss. This VMSS has a VM instance named aks-system-36934070-vmss_0 with a computer name (host name) aks-system-36934070-vmss000000
When querying the IMDS Service:
Currently, when using the resource detection processor for azure, this is what I see
Resource attributes:
-> host.name: Str(aks-system-36934070-vmss_0)
-> azure.vm.name: Str(aks-system-36934070-vmss_0)
-> azure.vm.scaleset.name: Str(aks-system-36934070-vmss)
From what I can gather, the value of compute.name and compute.osProfile.computerName is the same for non-VMSS/traditional standalone Virtual Machines.
Steps to Reproduce
- Run the collector with any configuration that uses the Azure resource detection processor in a Virtual Machine Scale Set (VMSS) VM.
- Below I pasted a config for kubernetes, but any config would work
Expected Result
Resource Attribute host.name should be populated using the value of IMDS' compute.osProfile.computerName.
In this example - aks-system-36934070-vmss000000.
Actual Result
Resource Attribute host.name is populated using the value of IMDS' compute.name In this example - aks-system-36934070-vmss_0.
Collector version
v0.138.0
Environment information
Environment
OS: Windows and Ubuntu
OpenTelemetry Collector configuration
exporters:
debug:
verbosity: detailed
processors:
resourcedetection/azure:
detectors: [azure]
timeout: 2s
override: false
receivers:
kubeletstats/workload:
auth_type: serviceAccount
collection_interval: 10s
endpoint: ${env:K8S_NODE_IP}:10250
extra_metadata_labels:
- container.id
- k8s.volume.type
insecure_skip_verify: true
k8s_api_config:
auth_type: serviceAccount
metric_groups:
- pod
- container
- volume
node: ${env:K8S_NODE_NAME}
service:
pipelines:
metrics:
exporters:
- debug
processors:
- resourcedetection/azure
receivers:
- kubeletstats/workload
telemetry:
logs:
level: infoLog output
NumberDataPoints #0
StartTimestamp: 2025-10-26 23:05:56 +0000 UTC
Timestamp: 2025-10-31 20:48:47.294641985 +0000 UTC
Value: 223756288
ResourceMetrics #106
Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1
Resource attributes:
-> k8s.pod.uid: Str(<HIDDEN>)
-> k8s.pod.name: Str(<HIDDEN>)
-> k8s.namespace.name: Str(<HIDDEN>)
-> k8s.volume.name: Str(<HIDDEN>)
-> cloud.provider: Str(azure)
-> cloud.platform: Str(azure_vm)
-> host.name: Str(aks-system-36934070-vmss_0)
-> cloud.region: Str(<HIDDEN>)
-> host.id: Str(<HIDDEN>)
-> cloud.account.id: Str(<HIDDEN>)
-> azure.vm.name: Str(aks-system-36934070-vmss_0)
-> azure.vm.size: Str(<HIDDEN>)
-> azure.vm.scaleset.name: Str(aks-system-36934070-vmss)
-> azure.resourcegroup.name: Str(<HIDDEN>)
ScopeMetrics #0
ScopeMetrics SchemaURL:
InstrumentationScope github.com/open-telemetry/opentelemetry-collector-contrib/receiver/kubeletstatsreceiver 0.138.0
Metric #0
Descriptor:
-> Name: k8s.volume.available
-> Description: The number of available bytes in the volume.
-> Unit: By
-> DataType: GaugeAdditional context
No response
Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.