[Entities] Overlapping attribute names in different entity types

[dmitryax]

Specific example: In a multi-zonal cluster, k8s.cluster and k8s.node entities can both have cloud.availability_zone attribute with different values.

The problem described in more detail in https://docs.google.com/document/d/1sUwKJEwPB89uA1jUrX6ea-w-mIYNk5TJ8NuMOAZfW2M/edit?tab=t.0 by @quentinmit.

We discussed this problem as part of Additional requirements for entities data model during Entities SIG meeting on Jan 16 and agreed on a solution that is closer to what's described as solution A in https://docs.google.com/document/d/1sUwKJEwPB89uA1jUrX6ea-w-mIYNk5TJ8NuMOAZfW2M/edit?tab=t.0#heading=h.ezgpqjbuutx8: do not attach both of the conflicting attributes to one resource, send the extra information in the side channel instead.

The argument against using different resource attributes (e.g. k8s.cluster.cloud.availability_zone and gcp.gce.instance.cloud.availability_zone) is that we could have the availability zone as a separate entity. In that case, we need one pre-defined identifying key (cloud.availability_zone). The information about relationships (k8s cluster -> AZ and k8s node -> AZ) can be sent separately in the entities side channel.

cc @tigrannajaryan

[quentinmit]

Why do you want to model the availability zone a separate entity? It's never a resource by itself; it only has any meaning in combination with a particular concrete resource. And different services may have a different set of zones (for example, Google App Engine uses different zone names from Google Compute Engine).

If you do model it as a separate entity, doesn't that mean that the zone would have to be omitted entirely from the resource attributes? Otherwise, which value would you use? That seems pretty unusable for downstream consumers.

[jsuereth]

If you do model it as a separate entity, doesn't that mean that the zone would have to be omitted entirely from the resource attributes? Otherwise, which value would you use? That seems pretty unusable for downstream consumers.

We discussed this in the meeting. The response there was that you'd pick ONE availability zone for the "lowest" or "most important" entity. and availability zone relationships would come out the entities signal itself.

I also have concerns with this approach not leading to good o11y. Particularly, I think consuming Resource itself becomes even more problematic. I actually consider cloud.availabiity_zone more of a "bug" at this point given what we have so far in semantic conventions. It's practically impossible to define that as an entity and ensure you can write a EntityDetector/ResourceDetector that gives you the right value generically. You would need intimate knowledge of which entity you are before you can look up the appropriate availability zone, which is why my PRIMARY reason I think this is a poor design choose for opentelemetry.

I'll try to write this down myself, but I'd challenge this proposal - Write Resource/Entity Detectors which can get the right availability zone between GKE vs. a single node and get it right, all the time. Particularly when using something like k8sattributereceiver.