open-telemetry
Introduce specification for OTel Profiles
Changes
Proposed change along with https://github.com/open-telemetry/semantic-conventions/pull/1329 to clarify the use of build_id in the context of OTel Profiles.
FYI: @open-telemetry/profiling-maintainers
- [ ] Related issues #
- [ ] Related OTEP(s) #
- [ ] Links to the prototypes (when adding or changing features)
- [x]
CHANGELOG.mdfile updated for non-trivial changes - [ ]
spec-compliance-matrix.mdupdated if necessary
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?
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
Mappingscould 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?
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".
This PR was marked stale due to lack of activity. It will be closed in 7 days.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Added the hash specification for process.executable.build_id.profiling` for https://github.com/open-telemetry/semantic-conventions/pull/1329.
As https://github.com/open-telemetry/semantic-conventions/pull/1329 got merged, is there something I can do to continue with this specification?
The hash algorithm as described in this document is essential for process.executable.build_id.profiling.
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
This PR was marked stale due to lack of activity. It will be closed in 7 days.
This PR was marked stale due to lack of activity. It will be closed in 7 days.
friendly ping @open-telemetry/technical-committee - can you provide some feedback why this change shouldn't move forward?
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.
This has enough approvals, including 2 from @open-telemetry/profiling-maintainers, so I am merging.