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.

[ChrsMark]

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?

No, I mean defining in SemConv spec the metrics and attributes we have already in the Collector. Most of the metrics are listed in the ongoing open-telemetry/semantic-conventions#1032, but we should also take care of the attributes.

My main concern here was if we should keep extending the "experimental" area before having a solid foundation for the k8s area in SemConv. In the past experimental metrics had to go through a painful deprecation process.

I know we discussed that already at #36862 as @dmitryax mentioned but is the plan to keep adding new entity attributes? If so we should let people know about this intention and let's ensure that we keep an eye for alignment with metric attributes like the k8s.namespace.phase I mentioned in the previous comment.

Note: not really blocking the addition, just seeking alignment on how we will proceed going forward.

[jinja2]

@ChrsMark Thanks for the feedback. I am looking to add a few more entity attributes for controllers (deployment and cronjob) in addition to this issue. I completely understand the need to keep entity attributes as closely aligned with the metric ones, and that even if we follow the existing ones, these might be deprecated with the ongoing semantic conventions work. I have been monitoring the new additions to semantic conventions to make sure these stay aligned with the new ones when applicable.

I'm open to any suggestions on these attributes and would be happy to bring this topic up during the next semantic conventions meeting to ensure we're all aligned.

[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/k8sclusterreceiver: @dmitryax @TylerHelmuth @povilasv @ChrsMark

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.