Correlate traces to profiles with the OTel ebpf profiler

[elsakeirouz]

Description

Based on Elastic's work to correlate traces to profiles for Java using the ebpf profiler.

[pr-commenter]

Benchmarks

Benchmark execution time: 2025-05-20 09:23:46

Comparing candidate commit 290c749 in PR branch elsa/trace-to-profile-corr with baseline commit e14a5a4 in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 1 metrics, 0 unstable metrics.

[elsakeirouz]

What do we think of using something like #ifdef linux/unix for parts that might not be relevant on Windows/MacOS? To be fair, since this code specifically is meant to work with the ebpf profiler on Linux, and will eventually only run if prompted, I do not see the point of compiling it on other OSs.

[dubloom]

What do we think of using something like #ifdef linux/unix for parts that might not be relevant on Windows/MacOS? To be fair, since this code specifically is meant to work with the ebpf profiler on Linux, and will eventually only run if prompted, I do not see the point of compiling it on other OSs.

My 2 cents here: if the code does not add a big compile time, I think we will pay more in code readibility by adding #ifdef (as the code is split into multiple files) than we will win in compile time. It can be worth adding some comments to tell it will only work in Linux though.
(Note this is my personal opinion and I'm not really a contributor of dd-trace-cpp atm).

[elsakeirouz]

What do we think of using something like #ifdef linux/unix for parts that might not be relevant on Windows/MacOS? To be fair, since this code specifically is meant to work with the ebpf profiler on Linux, and will eventually only run if prompted, I do not see the point of compiling it on other OSs.

My 2 cents here: if the code does not add a big compile time, I think we will pay more in code readibility by adding #ifdef (as the code is split into multiple files) than we will win in compile time. It can be worth adding some comments to tell it will only work in Linux though. (Note this is my personal opinion and I'm not really a contributor of dd-trace-cpp atm).

Noted, thanks for your input!

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 98.27586% with 1 line in your changes missing coverage. Please review.

Project coverage is 87.13%. Comparing base (e14a5a4) to head (290c749).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
src/datadog/tracer.cpp	95.83%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #197      +/-   ##
==========================================
+ Coverage   87.02%   87.13%   +0.11%     
==========================================
  Files          80       80              
  Lines        5140     5194      +54     
==========================================
+ Hits         4473     4526      +53     
- Misses        667      668       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[elsakeirouz]

FYI, the global variables' naming is not set in stone. We plan on moving towards something more generic that does not use the elastic name.

Additionally, I am in the process of a writing a problem statement regarding the way we share process data since dd-trace-cpp already shares that data through memfds.

[elsakeirouz]

What's left to do here is figure how we want to handle runtime-ids in case of forks.

[elsakeirouz]

Since we have not yet defined what the process storage is going to look like, I am not validating the data that is stored in there. Once that is specified, we can look into decoding the contents.

[r1viollet]

This part could be conditioned to an expected $TLS_DIALECT set above