Otel on Windows nodes - Host field with wrong value

[cesarfr1]

Otel collecting logs on Windows 2022 nodes.
For the host field, the customer is getting its pod name instead of the actual Windows Hostname.
The same behavior is not observed on Linux-based nodes.

[atoulme]

Please see https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/resourcedetectionprocessor

By default, we use the resourcedetectionprocessor with the system detector to determine the host name.

splunk-otel-collector-chart/helm-charts/splunk-otel-collector/templates/config/_common.tpl

Line 84 in cc8b2f9

- system

By default the system detector is set to use thehostname_sources ["dns", "os"] and a note in the documentation recommends for Windows hosts to use the lookup source instead.

To produce a FQDN, Windows hosts might have better results using the "lookup" hostname source, which is mentioned below.

Would you please try to customize the chart and add this additional source?

[omrozowicz-splunk]

So the additional context here was that the Windows Node was actually on VMware, managed by the openshift cluster. No resource detection settings worked for it. The ultimate workaround we used here was to update values.yaml with:

agent:
  extraEnvs:
    - name: OTEL_RESOURCE_ATTRIBUTES
      value: "host.name=$(K8S_NODE_NAME)"
  config:
    processors:
      resourcedetection:
        detectors: ["env"]

And this resulted in populating K8S_NODE_NAME env variable as the host name.

[omrozowicz-splunk]

Additionally, we will work on open-telemetry/opentelemetry-collector-contrib#21482 which will allow to choose what detectors will be used for setting up what attributes. So then we'll be able to use env only for host.name and not to loose other attributes.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. 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.

[atoulme]

This issue was fixed by @omrozowicz-splunk upstream. Thanks!