reduce service detector requirement for instance id

[brettmc]

Fixes #

Changes

The service resource detector SHOULD populate service.instance.id, however some runtimes (notably those frequently used for PHP) use a shared-nothing approach. This leads to a new instance id for each request, eg open-telemetry/opentelemetry-php#1643
Changing the requirement from an implied MUST to SHOULD allows implementations to deviate when necessary, which I plan to do for PHP SIG.

For non-trivial changes, follow the change proposal process.

• Related issues #
• Related OTEP(s) #
• Links to the prototypes (when adding or changing features)
• CHANGELOG.md file updated for non-trivial changes
• spec-compliance-matrix.md updated if necessary

[dyladan]

Think this may also affect lambda environments where each request potentially is a new service instance.

[dyladan]

Seems to me that rather than unpopulating service instance id, this raises the question of what a service instance is. If it is being triggered on each new request, that's probably not correct. But there is likely still some concept of a service instance. In lambda for example, it might be a new instance if there is a new deployment.

[jack-berg]

I think its a good default for SDKs to include a service.instance.id, and after lengthy discussions we determined that the best value we can do for this is a UUID. To me, the serverless is the exception to the rule, and users (and us via whatever examples they are following) should set an alternative stable service.instance.id value.

Alternatively, the service resource detector could have a config property for users to opt out of service.instance.id. 🤷

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[jpkrohling]

Should we consider doing the same for the service name that appears just before this?

[tsloughter]

@jpkrohling service name can already be set by an environment variable, so doesn't need this? I liked @jack-berg 's idea that sounds to me like making instance id similarly be able to be set. Then there is no need to make it optional.

[tsloughter]

Or no, can you not already do OTEL_RESOURCE_ATTRIBUTES=service.instance.id=my-lambda-instance-id and in the config file:

resource:
  attributes:
    - name: "service.instance.id"
      value: "my-lambda-instance-id"

The explanation of priority between this and the detectors is not clear as far as I can tell. The section on priority calls the env var "secondary" and seems to be referring to other resource information as what is provided by a user and the env var is somehow not provided by the user...

The SDK MUST extract information from the OTEL_RESOURCE_ATTRIBUTES environment variable and merge this, as the secondary resource, with any resource information provided by the user, i.e. the user provided resource information has higher priority.

But maybe I'm just reading this wrong and its meant to say env var attributes take precedence over other detected reosurces and those defined by the SDK like service.instance.id?

If others agree with this being unclear wording I can send a PR to try clearing it up, if my reading of it is correct.

[brettmc]

This is the bit of the spec that I'm struggling with:

The SDK MUST extract information from the OTEL_RESOURCE_ATTRIBUTES environment variable and merge this, as the secondary resource, with any resource information provided by the user, i.e. the user provided resource information has higher priority.

My interpretation is:

1. anything provided via OTEL_RESOURCE_ATTRIBUTES is highest priority -> should be the last detector to run
2. EXCEPT for OTEL_SERVICE_NAME -> so, service detector should run later than the detector which handles OTEL_RESOURCE_ATTRIBUTES, so that its service.name is higher priority (with service.instance.id coming along for the ride)

We have a bunch of optional and 3rd-party detectors, which are all executed before the service detector. If any of them were to provide service.instance.id, it would be clobbered by the service detector's UUID implementation. But, if we made them a higher priority than the service detector, they could in theory clobber service.name and anything provided through OTEL_RESOURCE_ATTRIBUTES.

Or no, can you not already do OTEL_RESOURCE_ATTRIBUTES=service.instance.id=my-lambda-instance-id

You could, that would give you a stable service instance id. But I don't think we can implement a detector to do the same, assuming the order of execution I've interpreted... 😕