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. 🤷