[receiver/k8scluster] adding more Node resource attributes

[povilasv]

Component(s)

receiver/k8scluster

Is your feature request related to a problem? Please describe.

I would like to use k8s cluster receiver to get more information about Node, such as Container Runtime Version, OS version and OS description.

Describe the solution you'd like

I propose to add these resource attributes added to Node metrics, which should be disabled by default:

  k8s.container_runtime.version:
    description: The version of container runtime used by Kubernetes Node.
    type: string
    enabled: false

  os.version:
    description: The version of operating system used by Kubernetes Node.
    type: string
    enabled: false

  os.description:
    description: The os description used by Kubernetes Node.
    type: string
    enabled: false

Describe alternatives you've considered

No response

Additional context

I did a POC and this is how it looks rendered, when using kind cluster:

k8s_node_allocatable_cpu{k8s_container_runtime_version="containerd://1.6.9", k8s_kubelet_version="v1.25.3", k8s_node_name="kind-control-plane", os_description="Ubuntu 22.04.1 LTS", os_version="6.6.8-arch1-1"}

Which seems to fit the Otel Semantic conventions in https://opentelemetry.io/docs/specs/semconv/resource/os/

[github-actions]

Pinging code owners for receiver/k8scluster: @dmitryax @TylerHelmuth @povilasv. See Adding Labels via Comments if you do not have permissions to add labels yourself.

[jinja2]

@povilasv I realize this has been merged already but just want to raise a small concern I have. Could mapping os.version attr to the kernel version value be confusing for nodes running linux distros? For instance, a node running Ubuntu 22.04, could the user be expecting the version id as seen in /etc/os-release which would be 22.04 in this case, instead of the kernel version (value in /proc/sys/kernel).
Screenshot with the 2 different versions for example

I don't see any guidance for differentiating distro vs kernel version in semantic-conventions, and it isn't that confusing so should be okay. Just thinking out loud if this could potentially be a source of confusion.

Additionally, what do you think about exposing the nodeInfo.operatingSystem as os.type attr for completeness and can give more context for os.version? I should mention though that this is also available as the k8s standard node label kubernetes.io/os which users might already be extracting.

[TylerHelmuth]

Which value between /etc/os-release or /proc/sys/kernel do you think is more "right"?

[jinja2]

To clarify, the kubelet is exposing the version info from /proc/sys/kernel as the kernelVersion field.

Which value between /etc/os-release or /proc/sys/kernel do you think is more "right"?

Both are technically right depending on whether you want the version of linux or of the distro. In this case, the accompanying os.description attribute which is the os name like Container-Optimized OS from Google or Ubuntu 22.04.3 LTS might set the expectation that the os.version is for the distro. Imo, adding os.type from nodeInfo. operatingSystem which will be set to linux/windows might make it more "correct" with os.version now referring to the os.type's version.

[povilasv]

I think it make sense to add os.type.

Regarding os.version I think we should rename it to kernel.version, given it's not OS version (Centos 7, Ubuntu 22, whatehever) but actual Linux kernel version.

This change wasn't yet released so we can do the breaking change.

Thoughts?

[povilasv]

looks like adding os.kernel.version is blocked by open-telemetry/semantic-conventions#66

[github-actions]

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 @open-telemetry/collector-contrib-triagers. 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.

Pinging code owners:

• receiver/k8scluster: @dmitryax @TylerHelmuth @povilasv

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[github-actions]

This issue has been closed as inactive because it has been stale for 120 days with no activity.