[PROF-7786] Include _dd.profiling.enabled tag #2913
Conversation
**What does this PR do?**: This PR implements the Datadog-internal "RFC: Identifying whether a span’s host has profiling enabled" similar to what [dd-trace-java](DataDog/dd-trace-java#5395) does by including a `_dd.profiling.enabled` tag when profiling is enabled. This is similar to the existing `_dd.appsec.enabled` tag. **Motivation**: This enables a better user experience in the "Code Hotspots" tab, e.g. for users that run profiling in a subset of their fleet. This way we can immediately tell them "hey, there's no profiling data" rather than making them wait a few minutes and then telling them that we didn't find anything. **Additional Notes**: N/A **How to test the change?**: Validate that the `_dd.profiling.enabled` tag shows up in the UX.
| profiling_enabled: | ||
| !!(defined?(Datadog::Profiling) && Datadog::Profiling.respond_to?(:enabled?) && Datadog::Profiling.enabled?), # rubocop:disable Style/DoubleNegation |
There was a problem hiding this comment.
I think this should be checked earlier and cached carefully if possible.
In today's world, I believe we can move this into the Tracing::Tracer object initialization process with no loss of correctness, then pass the value here.
There was a problem hiding this comment.
Good point. Fixed in cbe0317.
I had to do it lazily instead of during initialization to avoid any potential of loops (Profiling::Component taking an optional_tracer and doing something similar in the other direction), but otherwise it was a straightforward change.
|
Thanks Marco! I hope the trade-off for improving the user experience for the "Code Hotspots" when looking at at a trace is worth it. Especially since we're going to bring a lot of really cool features to the UX next -- stay tuned :) |
Not right now, because the profiler never gets called by the app, as it never instruments anything. You'll never see a profiler method sandwiched in between customer code, like you do for tracing/asm; it only sits in the background as a periodic observer. |
|
I think we need to revisit this. I don't think this is acceptable in its current state, but I want to review with stakeholders. |
What does this PR do?:
This PR implements the Datadog-internal
"RFC: Identifying whether a span’s host has profiling enabled" similar to what
dd-trace-java does by including a
_dd.profiling.enabledtag when profiling is enabled.This is similar to the existing
_dd.appsec.enabledtag.Motivation:
This enables a better user experience in the "Code Hotspots" tab, e.g. for users that run profiling in a subset of their fleet.
This way we can immediately tell them "hey, there's no profiling data" rather than making them wait a few minutes and then telling them that we didn't find anything.
Additional Notes:
N/A
How to test the change?:
Validate that the
_dd.profiling.enabledtag shows up in the UX.