Introduce specification for OTel Profiles

[florianl]

Changes

Proposed change along with open-telemetry/semantic-conventions#1329 to clarify the use of build_id in the context of OTel Profiles.

FYI: @open-telemetry/profiling-maintainers

• CHANGELOG.md file updated for non-trivial changes

[tigrannajaryan]

We don't yet have anything about profiles in the spec, this would be the first. I think we need to decide what sections about profiling we want in the spec. Is it going to be data model description?

Is data model going to be decoupled from its OTLP representation like we do for other signals (see log data model vs log proto or metric data model vs metric proto)?

Or do we think that OTLP representation is all we care about? In that case this clarification about Mappings could be added to proto.

@open-telemetry/profiling-maintainers @open-telemetry/spec-sponsors thoughts?

[felixge]

Is data model going to be decoupled from its OTLP representation like we do for other signals [...]

Or do we think that OTLP representation is all we care about? In that case this clarification about Mappings could be added to proto.

My initial preference would be to not maintain a separate data model description and focus on the OTLP representation. I'm assuming we can always come back to it and add an abstract data model description later?

[jsuereth]

My initial preference would be to not maintain a separate data model description and focus on the OTLP representation. I'm assuming we can always come back to it and add an abstract data model description later?

In my mind they're effectively the same thing, but the data model is a bit richer / filled with descriptions on usage and advanced concepts that may not be in the protocol.

E.g. a description on how to associate symbols back to profiles outside of the raw OTLP send is in your data model.

I agree that focusing on OTLP representaiton is priority #1 - but that's effectively working on the data model. You need a location to put information about how to consume and interpret the OTLP that goes beyond just "here's what this one message means".

[chalin]

I see that there is still active discussion about how to organize this new content, but if you do decide to create new section(s) then, see the inline suggestion.

[github-actions]

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

[florianl]

Added the hash specification for process.executable.build_id.profiling` for open-telemetry/semantic-conventions#1329.

[trask]

is there something I can do to continue with this specification?

hey @florianl! stuck spec PRs are not uncommon 😅 and there is some general guidance here: https://github.com/open-telemetry/opentelemetry-specification/blob/main/CONTRIBUTING.md#how-to-get-your-pr-merged

in this case I'd recommend reaching out to the profiling folks in the Profiling SIG meeting and in the #otel-profiling slack channel if you haven't already

[github-actions]

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

[felixge]

LGTM, thanks.

[svrnm]

lgtm

[felixge]

LGTM. Thanks 🙇

[github-actions]

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

[florianl]

friendly ping @open-telemetry/technical-committee - can you provide some feedback why this change shouldn't move forward?

[christos68k]

friendly ping @open-telemetry/technical-committee - can you provide some feedback why this change shouldn't move forward?

AFAIK no such decision was made. Github will mark PRs stale based on activity and close them after a few days. Usually someone with permissions to do so manually removes the label before that happens but we can always reopen the closed PR.

[tigrannajaryan]

LGTM, approving to make progress.

My question regarding what exactly we want to have in the spec repo for profiles (data model vs protocol details) I think still remains, but it is non blocking.

@open-telemetry/profiling-maintainers Please think about what structure of documents you would like to have for profiling in this repo.

[tigrannajaryan]

This has enough approvals, including 2 from @open-telemetry/profiling-maintainers, so I am merging.