Exclude process.executable entity from describing runtime

[thompson-tomo]

Fixes #

Changes

This ensures that the process.executable is not used to describe the runtime as we already have process.runtime for this. There is no benefit to also using process.executable given that it doesn't add anything of benefit to the user given that the build_id is not understandable by users.

Has also been discussed with the profiling sig to understand the usage of the build_id attribute: https://cloud-native.slack.com/archives/C03J794L0BV/p1778220434077029

Important

Pull requests acceptance are subject to the triage process as described in Issue and PR Triage Management.
PRs that do not follow the guidance above, may be automatically rejected and closed.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• Links to the prototypes or existing instrumentations (when adding or changing conventions)

[Gandem]

The profiler still needs process.executable (specifically build_id) when the executable is a runtime, in order to symbolize native frames from the runtime itself (e.g. function calls in the python / nodejs / ruby runtimes themselves). Dropping process.executable in those cases removes the symbolization metadata that buildid was originally introduced for.

IMHO process.executable and process.runtime still describe different things even when both relate to python: process.runtime captures the logical runtime typically emitted from inside the process by the runtime SDK, while process.executable captures the OS binary image (basename of /proc/[pid]/exe, build_id for symbolization) as observed externally. They serve distinct consumers (language SDKs vs profilers/symbolizers), so there's no real overlap to remove.

[thompson-tomo]

As per discussion on slack, this change is purely focussed on describing the entity (resource) use case, the ability to include the attributes on the attribute on the mapping is unaffected.

[florianl]

sorry for catching up just now. I agree with @Gandem and that the proposed change in note and brief are breaking changes for Profiling.
Instead, I think, it would be better to rephrase it to clearify its purpose. At the moment it reads to me, like there could be only a single process.executable..... So maybe something like A executable of a process and Represents a executable file associated with a process. This single execitable may be run by multiple process instances.

[thompson-tomo]

@florianl i am not following, this note/brief is on the entity which can only be on a resource hence the resource can only contain 1 executable. The usage of the attributes at other locations ie mappings is unchanged.

What part of the brief change would be a breaking change given that it only was just recently split out of the process entity? This in fact preserves the previous behaviour where the attributes where within the process entity.

What part of the note change is a breaking change? Up until the latest release, only path/name existed on an entity/resource.

[florianl]

I have concerns regarding the statement, [..] it should not be used when the executable corresponds to the runtime.. We should avoid requiring a different attribute based on whether a match occurs, especially given that the definition of runtime remains unclear. As an end user, I expect an executable to consistently use the same attribute.

[thompson-tomo]

We already the definition of process.runtime if we need to clarify and improve that, let's do so. We could even add the htlhash to the runtime if you think that is of value. That way on a profile payload you could have both the hash of the executable and the runtime at the resource level.

I would argue as an end-user I am interested in what piece of code has been executed and has lead to the telemetry being generated. The runtime is of much less significance.

This approach for me increases consistency as it will ensure the executable always corresponds to what was executed to generate the telemetry. Note It was the feedback on slack to ensure scripts don't overload the executable hence splitting them.

[thompson-tomo]

@florianl following up on this. Please note, the brief is only referring to the usage of the entity & the corresponding attributes as part of the resource.

The usage of the process.executable attributes elsewhere is unaffected. This means that the only difference to prior to #3536 was merged is that name & path would not appear on the resource. However with #3686 path would return as entrypoint on the process entity hence there should not be an impact on profiling.

[florianl]

As the current state of the change still mentions [..] but it should not be used when the executable corresponds to the runtime., I'm still concerned about this change.

[thompson-tomo]

I am not following Where exactly the concern is?

The profiles/mapping message etc can still reference/use process.executable.* attributes even to describe the runtime which and that will not change. All that is impacted is the resource attributes dictionary contents hence why the note is on the entity.

[thompson-tomo]

@florianl i have reworded the note to make it clearer that the note corresponds to resource attributes please review as there should be nothing causing an issue for profiling when comparing to the state prior to #3536.

[github-actions]

This PR has been labeled as stale due to lack of activity. It will be automatically closed if there is no further activity over the next 7 days.

[github-actions]

This PR has been labeled as stale due to lack of activity. It will be automatically closed if there is no further activity over the next 7 days.

[github-actions]

This PR has been labeled as stale due to lack of activity. It will be automatically closed if there is no further activity over the next 7 days.

[Copilot]

Pull request overview

This PR updates the process entity definitions to clarify that process.executable should not be used to describe a language runtime, and that process.runtime is the appropriate entity for runtime details.

Changes:

• Adds/adjusts entity text for process.runtime and process.executable to clarify intended usage (especially around runtime vs executable identity).
• Updates generated registry documentation to reflect the updated process.executable description.
• Adds a changelog entry describing the clarification.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
model/process/entities.yaml	Updates entity brief/note guidance for process.runtime and process.executable.
docs/registry/entities/process.md	Regenerates/updates the registry description for process.executable to match the model.
.chloggen/executable_usage.yaml	Adds release-note entry for the behavior clarification.

[opentelemetry-pr-dashboard]

Pull request dashboard status

Status last refreshed: 2026-07-25 21:52:37 UTC.

• Waiting on: Reviewers
• Next step: Review the latest changes.

This automated status or its linked feedback items may be incorrect. If something looks wrong, please report it with the result you expected.