feat(profiling): Add setting to omit local root span id from serialized pprof [PROF-15045]#2104
Conversation
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: 49e154d | Docs | Datadog PR Page | Give us feedback! |
… pprof **What does this PR do?** This PR adds a new API to profiles: `set_omit_local_root_span_id_when_serializing`. This API can be used to omit the `local root span id` from serialized pprof files. **Note that nothing else changes**: The `local root span id` is still being tracked and used for everything in the profile, only never actually written in the pprof. Also, this is off by default and needs to be set on every profile before serialization (gets disabled again on profile reset). **Motivation:** In <https://datadoghq.atlassian.net/wiki/spaces/PROF/pages/6821413373/ADR+2026-06-04.1+Continue+using+span-child+filter+mode+remove+local-root-span+backend+support> we discussed experimenting with having libraries not emit local root span id. This is very relevant for implementing OTel thread context, since "local root span" is not a common otel concept and we need to do extra work in all libraries to try to keep it. Having this in libdatadog and in an off-by-default opt-in-api will allow us to easily test this. **Additional Notes:** N/A **How to test the change?** This change includes test coverage. I plan to wire this up to dd-trace-rb and add an end-to-end test there.
6e61d14 to
8ed96aa
Compare
local root span id from serialized pproflocal root span id from serialized pprof
Clippy Allow Annotation ReportComparing clippy allow annotations between branches:
Summary by Rule
Annotation Counts by File
Annotation Stats by Crate
About This ReportThis report tracks Clippy allow annotations for specific rules, showing how they've changed in this PR. Decreasing the number of these annotations generally improves code quality. |
local root span id from serialized pproflocal root span id from serialized pprof [PROF-15045]
danielsn
left a comment
There was a problem hiding this comment.
I guess we still need to set the local-root-span as a label to get the endpoint?
Yes -- this is why the change is only on the serializer; we're currently using the "local root span id" as a key for updating the endpoint later. In the future, libraries could keep using local root span id as the key, or may use any other key (e.g. can even be a ever-incrementing counter, libdatadog doesn't particularly care) but for now I didn't want to touch those interfaces/APIs. |
Artifact Size Benchmark Reportaarch64-alpine-linux-musl
aarch64-unknown-linux-gnu
libdatadog-x64-windows
libdatadog-x86-windows
x86_64-alpine-linux-musl
x86_64-unknown-linux-gnu
|
e35c67d to
49e154d
Compare
What does this PR do?
This PR adds a new API to profiles:
set_omit_local_root_span_id_when_serializing. This API can be used to omit thelocal root span idfrom serialized pprof files.Note that nothing else changes: The
local root span idis still being tracked and used for everything in the profile, only never actually written in the pprof. Also, this is off by default and needs to be set on every profile before serialization (gets disabled again on profile reset).Motivation
In https://datadoghq.atlassian.net/wiki/spaces/PROF/pages/6821413373/ADR+2026-06-04.1+Continue+using+span-child+filter+mode+remove+local-root-span+backend+support we discussed experimenting with having libraries not emit local root span id. This is very relevant for implementing OTel thread context, since "local root span" is not a common otel concept and we need to do extra work in all libraries to try to keep it.
Having this in libdatadog and in an off-by-default opt-in-api will allow us to easily test this.
Additional Notes
N/A
How to test the change?
This change includes test coverage. I plan to wire this up to dd-trace-rb and add an end-to-end test there.