Add container.health and container.status to container attributes

[Markus78]

Area(s)

area:container

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

It is usefull to be able to the tell the health and status of running containers in docker or podman. These attributes would make it easier to keep track of the status of containers and their health.

Describe the solution you'd like

I would like 2 new attributes for containers

Name: container.health integer with the following definitions

Value	Description
-1	unknown ( no healthcheck exists )
0	healthy
1	unhealthy
2	starting

Name: container.status integer with the following definitions

Value	Description
-1	unknown
0	created
1	error
2	exited
3	paused
4	running
5	degraded
6	stopped

These 2 attributes makes overview of running containers possible. Inspiration from prometheus-podman-exporter

Describe alternatives you've considered

No response

Additional context

No response

[ChrsMark]

Hey @Markus78!

Could these be modeled as metrics like the hw.status in https://opentelemetry.io/docs/specs/semconv/system/hardware-metrics/#hwbattery---battery-metrics as it was suggested at #1032 (comment)?

My second question is if these two metrics could be re-used as K8s related metrics as well. For example there is https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/k8sclusterreceiver/documentation.md#k8scontainerready but I'm not sure if we could expand here and have a common set of metrics for both K8s and generic containers. Also there is open-telemetry/opentelemetry-collector-contrib#35668. @povilasv do you have any thoughts on this?

/cc @open-telemetry/semconv-container-approvers @open-telemetry/semconv-k8s-approvers

[povilasv]

Some points:

1. I don't think k8s.container has same statuses as:

-1	unknown
0	created
1	error
2	exited
3	paused
4	running
5	degraded
6	stopped

In k8s case it's more like - Waiting, Running, Terminated, Unknown.

There is also question whether other container manager have same statuses as well. If they don't, then container namespace doesn't really work 🤔

2. Question should we encode values as numbers? There is a long standing issue in OTEL regarding metrics - Does OpenTelemetry need "enum" metric type? opentelemetry-specification#1711 I think it should also applie to attibutes

[ChrsMark]

Question should we encode values as numbers? There is a long standing issue in OTEL regarding metrics - open-telemetry/opentelemetry-specification#1711 I think it should also applie to attibutes

It seems we would be able to describe state/status/phase metrics using the modeling already used in the hw metrics:
#1032 (comment)

[rogercoll]

In k8s case it's more like - Waiting, Running, Terminated, Unknown.

Agree, this the ContainerState K8s protobufs definition:

type ContainerState struct {
	// Details about a waiting container
	// +optional
	Waiting *ContainerStateWaiting `json:"waiting,omitempty" protobuf:"bytes,1,opt,name=waiting"`
	// Details about a running container
	// +optional
	Running *ContainerStateRunning `json:"running,omitempty" protobuf:"bytes,2,opt,name=running"`
	// Details about a terminated container
	// +optional
	Terminated *ContainerStateTerminated `json:"terminated,omitempty" protobuf:"bytes,3,opt,name=terminated"`
}