pub const SERVICE_INSTANCE_ID: &str = "service.instance.id";Expand description
The string ID of the service instance.
MUST be unique for each instance of the same service.namespace,service.name pair (in other words
service.namespace,service.name,service.instance.id triplet MUST be globally unique). The ID helps to
distinguish instances of the same service that exist at the same time (e.g. instances of a horizontally scaled
service).
Implementations, such as SDKs, are recommended to generate a random Version 1 or Version 4 RFC
4122 UUID, but are free to use an inherent unique ID as the source of
this value if stability is desirable. In that case, the ID SHOULD be used as source of a UUID Version 5 and
SHOULD use the following UUID as the namespace: 4d63009a-8d0f-11ee-aad7-4c796ed8e320.
UUIDs are typically recommended, as only an opaque value for the purposes of identifying a service instance is
needed. Similar to what can be seen in the man page for the
/etc/machine-id file, the underlying
data, such as pod name and namespace should be treated as confidential, being the user's choice to expose it
or not via another resource attribute.
For applications running behind an application server (like unicorn), we do not recommend using one identifier for all processes participating in the application. Instead, it's recommended each division (e.g. a worker thread in unicorn) to have its own instance.id.
It's not recommended for a Collector to set service.instance.id if it can't unambiguously determine the
service instance that is generating that telemetry. For instance, creating an UUID based on pod.name will
likely be wrong, as the Collector might not know from which container within that pod the telemetry originated.
However, Collectors can set the service.instance.id if they can unambiguously determine the service instance
for that telemetry. This is typically the case for scraping receivers, as they know the target address and
port.
§Examples
627cc493-f310-47de-96bd-71410b7dec09