add entity metadata - namespace and container

[jinja2]

Component(s)

receiver/k8scluster

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

I'd like to introduce some some additional descriptive attributes to the experimental k8s.namespace and container entities that are emitted from the k8scluster receiver.

Describe the solution you'd like

Add to k8s.namespace the attributes -

• k8s.namespace.phase - Values can be active, terminating, unknown.
• k8s.namespace.creation_timestamp - The creation timestamp of namespace object.

Add to container entity the attribute -

• container.creation_timestamp - This is the timestamp the container was started at. The attribute is available when the state of the container is running or terminated (waiting container does not have this attr). Note, for other entities like namespace the creation_timestamp is the time from metadata of the object, whereas for a container this is the StartedAt field from the containerStatus. I am not certain if we want to make this distinction here with a different key, e.g. container.started_at.

Describe alternatives you've considered

No response

Additional context

On a previous PR, we discussed tracking these entity attrs in an issue in sem-conv. The tracking issue is #1693.

[github-actions]

Pinging code owners:

• receiver/k8scluster: @dmitryax @TylerHelmuth @povilasv @ChrsMark

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

[bacherfl]

(Triage): removing needs-triage as the issue is well formulated, adding waiting-for-code-owners

[ChrsMark]

FYI there is already the k8s.namespace.phase attribute defined in attributes registry.
This is used by the k8s.namespace.phase metric.

One important thing that we need to ensure here is that such attributes can indeed be used as metric attributes and as entity attributes if needed. The k8s.namespace.phase is well aligned with that.

Probably we can already start adding attributes to the registry: https://github.com/open-telemetry/semantic-conventions/blob/main/docs/attributes-registry/k8s.md

In general I would feel more comfortable with adding new stuff after we have completed the transition of the existing k8s metrics/attributes to SemConv.

[jinja2]

One important thing that we need to ensure here is that such attributes can indeed be used as metric attributes and as entity attributes if needed. The k8s.namespace.phase is well aligned with that.

I am trying to keep the entity attributes aligned with the metrics ones as much as I can.

Probably we can already start adding attributes to the registry: https://github.com/open-telemetry/semantic-conventions/blob/main/docs/attributes-registry/k8s.md

Sure, I can start looking into adding these. I think I'll need some guidance, probably from sem-conv maintainers, around how to add these but with additional qualifiers about these being non-identifying/descriptive attributes which maybe mutable.

In general I would feel more comfortable with adding new stuff after we have completed the transition of the existing k8s open-telemetry/semantic-conventions#1032 to SemConv.

Sorry, do you mean adding these to the receiver?

[dmitryax]

@ChrsMark this is similar to #36862 where we agreed to keep mentioning the entity attributes in open-telemetry/semantic-conventions#1693.

Let's align with the existing metric names. However, it doesn't seem necessary to block the work on the experimental entities by the semantic conventions for other entity attributes, given that they can easily be changed going forward.

We could also start adding them in semantic conventions, but this could overload the current k8s stabilization work.