[receiver/kubeletstats] Add k8s.{container,pod}.memory.node.utilization metrics

[ChrsMark]

Description:

Similar to #32295 and #33390, this PR adds the k8s.{container,pod}.memory.node.utilization metrics.

Link to tracking Issue: #27885

Testing: Added unit test.

Documentation: Added

Manual testing

1. Using the following target Pod:

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
spec:
  containers:
  - name: memory-demo-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "8070591Ki"
      limits:
        memory: "9070591Ki"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "800M", "--vm-hang", "4"]

On a node of 32,5G memory the 800Mb container/Pod consumes the 0.8/32.5=0.0246...=0.025.

[dmitryax]

I missed why did we go with the dots instead of memory_node_utilization. All the parts in k8s.{container,pod}.memory are proper namespaces, but none of memory.node.utilization part sound like namespaces

[ChrsMark]

I missed why did we go with the dots instead of memory_node_utilization. All the parts in k8s.{container,pod}.memory are proper namespaces, but none of memory.node.utilization part sound like namespaces

A valid alternative would be k8s.{container,pod}.memory.node_utilization since k8s.{container,pod}.memory must be a namespace to accommodate for other memory metrics as well, right?

Based on this, instead of k8s.{container,pod}.memory.node_utilization choosing k8s.{container,pod}.memory.node.utilization preserves us the space for the (unlikely but existing) scenario where we would need to add extra metrics like the node.allocatable_utilization or whatever (based on Node's limits/characteristics/status), either emitted by the Collector or calculated and stored by a back-end.
Also based on the issues that affect SemConvs that have underscores (open-telemetry/semantic-conventions#1118) I think going with dots is a safer option here since we don't violate any other rule (ie a metric cannot be a namespace at the same time)

[ChrsMark]

@TylerHelmuth @dmitryax Anything else missing here?

[rogercoll]

LGTM

[andrzej-stencel]

I missed why did we go with the dots instead of memory_node_utilization. All the parts in k8s.{container,pod}.memory are proper namespaces, but none of memory.node.utilization part sound like namespaces

A valid alternative would be k8s.{container,pod}.memory.node_utilization since k8s.{container,pod}.memory must be a namespace to accommodate for other memory metrics as well, right?

Based on this, instead of k8s.{container,pod}.memory.node_utilization choosing k8s.{container,pod}.memory.node.utilization preserves us the space for the (unlikely but existing) scenario where we would need to add extra metrics like the node.allocatable_utilization or whatever (based on Node's limits/characteristics/status), either emitted by the Collector or calculated and stored by a back-end. Also based on the issues that affect SemConvs that have underscores (open-telemetry/semantic-conventions#1118) I think going with dots is a safer option here since we don't violate any other rule (ie a metric cannot be a namespace at the same time)

Also see this discussion in similar PR:

• [receiver/kubeletstats] Add k8s.container.cpu.node.utilization metric  #32295 (comment)

There, the metric name evolved from k8s.container.cpu_limit_utilization to k8s.container.cpu.node_utilization to k8s.container.cpu.node.utilization. The last change was motivated by the fact that you could have different kinds of "utilization", based either on the node's full CPU capacity or only the node's allocatable CPU resources.