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
- 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.
- 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
- Otel spec: https://opentelemetry.io/docs/specs/otel/resource/semantic_conventions/container/
- 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.*.
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:
Open questions
container.image.tagfield (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 forcontainer.image.hash.Resources
This is also related to #58 since we might consider using
container.cpu.*instead ofkubernetes/k8s.container.cpu.*.