|
9 | 9 |
|
10 | 10 | - [Minimally Sufficient Identity](#minimally-sufficient-identity) |
11 | 11 | - [Repeatable Identity](#repeatable-identity) |
| 12 | +- [Identifying Attributes](#identifying-attributes) |
12 | 13 | - [Examples of Entities](#examples-of-entities) |
13 | 14 |
|
14 | 15 | <!-- tocstop --> |
@@ -117,6 +118,30 @@ describing the process. |
117 | 118 | > identity from a central registry or knowledge store, OpenTelemetry must |
118 | 119 | > support all possible scenarios. |
119 | 120 |
|
| 121 | +## Identifying Attributes |
| 122 | + |
| 123 | +OpenTelemetry Semantic Conventions MUST define a set of identifying attribute |
| 124 | +keys for every defined entity type. |
| 125 | + |
| 126 | +Names of the identifying attributes SHOULD use the entity type as a prefix to avoid |
| 127 | +collisions with other entity types. For example, the `k8s.node` entity uses |
| 128 | +`k8s.node.uid` as an identifying attribute. |
| 129 | + |
| 130 | +When an entity can be emitted by multiple observers, the following rules apply: |
| 131 | + |
| 132 | +* Two independent observers that report the same entity MUST be able to |
| 133 | + supply identical values for all identifying attributes. |
| 134 | + |
| 135 | +* If an observer cannot reliably obtain one or more identifying attributes, it |
| 136 | + MUST NOT emit telemetry using that entity type. Instead, it SHOULD: |
| 137 | + 1. delegate to the observer that _can_ supply the full set and treat that |
| 138 | + observer as the _source of truth_, or |
| 139 | + 2. emit a _different_ entity type with a set of identifying attributes it |
| 140 | + can populate reliably. |
| 141 | + |
| 142 | +This ensures that entity identity is consistent and unambiguous across |
| 143 | +observers. |
| 144 | + |
120 | 145 | ## Examples of Entities |
121 | 146 |
|
122 | 147 | _This section is non-normative and is present only for the purposes of |
|
0 commit comments