Skip to content

Commit

Permalink
final clarifications, rebase
Browse files Browse the repository at this point in the history
Signed-off-by: Juraci Paixão Kröhling <[email protected]>
  • Loading branch information
jpkrohling committed Oct 19, 2023
1 parent 93db8a2 commit 2d23626
Showing 1 changed file with 7 additions and 3 deletions.
10 changes: 7 additions & 3 deletions model/resource/service_experimental.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -29,20 +29,24 @@ groups:
(e.g. instances of a horizontally scaled service). It is preferable for the ID to be persistent
and stay the same for the lifetime of the service instance, however it is acceptable that
the ID is ephemeral and changes during important lifetime events for the service
(e.g. service restarts).
If the service has no inherent unique ID that can be used as the value of this attribute
(e.g. service instance restarts).
If the instance has no inherent unique ID that can be used as the value of this attribute
it is recommended to generate a random Version 1 or Version 4
[RFC 4122](https://www.ietf.org/rfc/rfc4122.txt) UUID. Services aiming for reproducible UUIDs may also
use Version 5. UUIDs are typically recommended, as we only need an opaque yet reproducible value for
the purposes of identifying a service instance. 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
[`/etc/machine-id`](https://www.freedesktop.org/software/systemd/man/machine-id.html) file, the underlying data, such as pod name and namespace should be treated as
confidential by this algorithm, being the user's choice to expose it or not via another resource attribute.
When a UUID v5 is generated, the UUID's namespace MUST be set to:
`${telemetry.sdk.name}.${telemetry.sdk.language}.${service.name}`, so that the same service yields the
same ID if the same value (`host.id`, `/etc/machine-id`, and so on) remains the same. It would still
yield different results for different services on the same host.
Users running their services on platforms such as Kubernetes are encouraged to explicitly set the
`service.instance.id` using their existing automation, or by setting a value that can be used for a
consistent value, such as `container.id`.
SDKs are required to use the following algorithm when generating `service.instance.id`:
- If the user has provided a `service.instance.id`, via environment
Expand Down

0 comments on commit 2d23626

Please sign in to comment.