[entities] Do we allow different identifying attributes?

[dmitryax]

After prototyping entity detection in the collector open-telemetry/opentelemetry-collector-contrib#35538, we found that some detectors currently cannot provide the same set of identifying attributes for the same type. For example, most of the detectors detecting a host entity type can provide host.id while the docker detector currently can only provide host.name.

This particular issue with the docker detector can potentially be mitigated by:

1. Updating the docker detector to provide host.id. To be investigated.
2. If 1 isn't possible, the entity type can potentially be called differently.

Even if we have a solution for this particular case, it's possible to run into other cases like this with other entity types. We can keep tracking them in this issue.

Based on the observations, we need to decide if we strictly define a set of identifying attributes for a particular entity type or keep it open while providing a list of recommended attributes.

[jsuereth]

2025-03-06 - We think in Semantic Conventions we should not allow different "key" values for identifying attributes on a host.

However, users are free to create Entities as they need. If they put different keys here, that would be allowed and not prevented by SDKs. (partially, we cannot enforce semconv generically in SDKs, as that would mean they need access to semconv).

We still need to sort of "navigationality" vs. "minimal keys" for attributes. E.g using UUIDs vs a series of KRM names in k8s.* namespace.

We will sort out that decision in the future

[jsuereth]

Next step here -

We want to document our proposed multi-observer solution. Simple gist - we create a entity like Observed Service or just Server that has host/port and later declare a relationship with a more specific entity "is" that same service, so one observer can report the simple entity, a better observer gets the specific one.