Consider adopting more container fields from ECS

[ChrsMark]

Based on https://opentelemetry.io/docs/specs/otel/resource/semantic_conventions/container/ the most important Containers' fields are already part of the spec. This issue aims to make a comparison with the respective ECS fields and evaluate the adoption (from ECS) of any fields missing.

Comparison table

Here is a comparison matrix between the ECS container fields and the open-telemetry ones:

OTel	ECS	Match	Type
container.name	container.name	✔️	keyword
container.id	container.id	✔️	keyword
container.runtime	container.runtime	✔️	keyword
container.image.name	container.image.name	✔️	keyword
container.image.tags	container.image.tag	❌	array
container.image.repo_digests/oci.manifest.digest	container.image.hash.all	❌	array
container.labels	container.labels	✔️	object
	container.memory.usage		scaled_float
	container.cpu.usage		scaled_float
	container.disk.read.bytes		long
	container.disk.write.bytes		long
	container.network.egress.bytes		long
	container.network.ingress.bytes		long

Open questions

1. As it is shown in the table above we would need to come to a decision for the type of the container.image.tag field (string VS array). In ECS this is an array storing all of the image's tags but to my mind this is not correct since 1 container will only be linked to 1 image tag. I would agree with what Otel specifies today regarding the type. Most probably the same goes for container.image.hash.
2. Many of the container's resource utilization fields that are present in ECS can be considered to be part of the Otel spec as well. Same for the container's labels.

Resources

1. Otel spec: https://opentelemetry.io/docs/specs/otel/resource/semantic_conventions/container/
2. ECS spec: https://www.elastic.co/guide/en/ecs/current/ecs-container.html#ecs-container

This is also related to #58 since we might consider using container.cpu.* instead of kubernetes/k8s.container.cpu.*.

[joaopgrassi]

I guess we should consider this other issue, and how adopting fields from ECS would work with those from OCI? #48 (comment)

[ChrsMark]

Good catch @joaopgrassi !

Yeap it seems that for container.image.* fields we can consider following what #48 suggests. However what bugs me here is the Images and artifacts are not strictly related to containers fact which might not be so accurate here since we have to do with containers actually? Btw, ECS seems to be closer to that assumption that's why image.tag and image.hash are arrays. But I think it would worth revisiting this and check how useful this approach can be.

Apart from the image.* fields, the rest of the fields that are mentioned in the diff seem to be irrelevant to #48, right? If so, how about handling them separately so as to not block the rest of the migration?

[joaopgrassi]

Apart from the image.* fields, the rest of the fields that are mentioned in the diff seem to be irrelevant to #48, right? If so, how about handling them separately so as to not block the rest of the migration?

@ChrsMark Makes sense to me!

[ChrsMark]

Since #282 has been merged we can close this as completed 🎂 .

Having said this, we can consider the container ECS fields as merged with OpenTelemetry's container SemConvs 🎉 🥳 .