Include service.instance.id Resource attribute #5257

Activity

1. herin049

   added

   feature-request

   on May 30, 2026
2. herin049

   self-assigned this

   on May 30, 2026
3. herin049

   changed the title [-]Include service.instance.id Resource attribute by default[/-] [+]Include service.instance.id Resource attribute[/+] on May 30, 2026
4. aabmass commented on Jun 4, 2026

   

   aabmass

   on Jun 4, 2026

   Member

   More actions

   From the SIG call

   • this is stable in semconv
   • [aaron] awesome thank you for sending this
   • Declarative config has its own impl. We can use this new PR’s impl to consolidate.

   From aaron, does this cover forking cases correctly? We might need to embed this more deeply in the Resource SDK to mutate resource when fork happens.
5. herin049 commented on Jun 4, 2026

   

   herin049

   on Jun 4, 2026

   ContributorAuthor

   More actions

   @aabmass After thinking about it more, I think the discussion around forking behavior should be treated as an independent issue. For example, there is already an issue when using the ProcessResourceDetector with forking because the process.pid will not be correctly reflected post-fork.

   One solution would be to expose a mechanism to modify the Resource object at runtime on the TracerProvider and perform an update for the resource object for each registered Tracer (and analogously for metrics/logs) by using a function registered using os.register_at_fork(). Wdyt?
6. aabmass commented on Jun 5, 2026

   

   aabmass

   on Jun 5, 2026

   Member

   More actions

   I agree it's not specific to service.instance.id, but I don't think we should open a public way to mutate Resource now.

   Are you saying we should merge #5259 at first without specific forking logic? I'm ok with that too, and maybe open a new tracking bug for the forking issue with resource?
7. herin049 commented on Jun 6, 2026

   

   herin049

   on Jun 6, 2026

   ContributorAuthor

   More actions

   I agree it's not specific to service.instance.id, but I don't think we should open a public way to mutate Resource now.

   Are you saying we should merge #5259 at first without specific forking logic? I'm ok with that too, and maybe open a new tracking bug for the forking issue with resource?

   @aabmass I've opened #5279 and #5280 to add the ability to refresh process sensitive Resource attributes. I did decide to add one public API function to allow users to update the Resource on a provider post-initialization by calling provider.update_resource(...) given that there may be fringe use cases where this is needed by users. However, I'm also open to keeping this method private. Let me know what you think.

   👍React with 👍2Reacted by Aaron Abbott and Emídio
8. emdneto commented on Jun 9, 2026

   

   emdneto

   on Jun 9, 2026

   Last edited by emdneto

   Member

   More actions

   There's also #5000 @herin049. wdyt?
9. herin049 commented on Jun 9, 2026

   

   herin049

   on Jun 9, 2026

   Last edited by herin049

   ContributorAuthor

   More actions

   There's also #5000 @herin049. wdyt?

   @emdneto Although I'm a bit biased here, I would generally prefer #5280 over #5000 since it is a more general solution that allows any resource detector to declare if it is process sensitive. That is, is also solves the issue for the process resource detector which doesn't work with forking. Also, it also appears that #5000 doesn't correctly solve the issue because it doesn't update the resource for already created tracers/loggers.

   👍React with 👍1Reacted by Emídio

   👀React with 👀1Reacted by Nicolas Sterchele
10. sterchelen commented on Jun 11, 2026

    

    sterchelen

    on Jun 11, 2026

    More actions

    since it is a more general solution that allows any resource detector to declare if it is process sensitive. That is, is also solves the issue for the process resource detector which doesn't work with forking. Also, it also appears that #5000 doesn't correctly solve the issue because it doesn't update the resource for already created tracers/loggers.

    @herin049 — you're right, and I'd rather we converge than have two competing PRs. A few notes after digging into yours.

    Each provider's _handle_fork() calls _get_process_sensitive_resource() independently. For process.pid that's fine — it's deterministic within a process. But a random service.instance.id would come out different for the meter, tracer and logger providers in the same worker. That cross-signal consistency is exactly why #5000 moved to a single shared UUID.

    So if we want to close #5000 we need to address this in #5280 properly
11. herin049 commented on Jun 11, 2026

    

    herin049

    on Jun 11, 2026

    ContributorAuthor

    More actions

    since it is a more general solution that allows any resource detector to declare if it is process sensitive. That is, is also solves the issue for the process resource detector which doesn't work with forking. Also, it also appears that #5000 doesn't correctly solve the issue because it doesn't update the resource for already created tracers/loggers.

    @herin049 — you're right, and I'd rather we converge than have two competing PRs. A few notes after digging into yours.

    Each provider's _handle_fork() calls _get_process_sensitive_resource() independently. For process.pid that's fine — it's deterministic within a process. But a random service.instance.id would come out different for the meter, tracer and logger providers in the same worker. That cross-signal consistency is exactly why #5000 moved to a single shared UUID.

    So if we want to close #5000 we need to address this in #5280 properly

    @sterchelen This is already accounted for in #5259
12. aabmass

    closed this as completedin #5259on Jun 11, 2026