-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix missing endpoint profiling when request_queuing is enabled in rack instrumentation #3109
Fix missing endpoint profiling when request_queuing is enabled in rack instrumentation #3109
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3109 +/- ##
==========================================
- Coverage 98.16% 98.15% -0.01%
==========================================
Files 1323 1323
Lines 75155 75160 +5
Branches 3428 3428
==========================================
+ Hits 73773 73775 +2
- Misses 1382 1385 +3
... and 1 file with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
int root_span_type_length = RSTRING_LEN(root_span_type); | ||
const char *root_span_type_value = StringValuePtr(root_span_type); | ||
|
||
return (root_span_type_length == strlen("web") && (memcmp("web", root_span_type_value, strlen("web")) == 0)) || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since you are potentially doing 2 strlen()
calls per string per call does it make sense to make these constants so we don't evaluate them every function call?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is strlen
on a constant string, the compiler will optimize it away, even at -O0
, see: https://godbolt.org/z/Wb351Monv :)
…k instrumentation **What does this PR do?** This PR tweaks the logic that decides if the profiler should collect the resource from an active trace to also consider the span type `proxy`, which is used when the `request_queuing` feature is in use in the rack instrumentation. Without this fix, the endpoint profiling feature (e.g. allowing customers to drill into their profiles by endpoint) does not work in combination with `request_queuing`, and the feature is hidden in the profiler UX. **Motivation:** Make sure that customers that enable `request_queuing` are still able to look at their profiles per-endpoint. **Additional Notes:** N/A **How to test the change?** The change includes test coverage. If you're interested in testing it out with a real http app, you can do so by enabling the `request_queuing` feature: ```ruby Datadog.configure do |c| c.tracing.instrument :rack, request_queuing: true end ``` and then perform a request to the app including the `X-Request-Start` header: ``` $ curl --header "X-Request-Start: t=1693901946000" http://localhost:8080/foo ``` This will generate a `queue` span, and with this change, the endpoint will show up in the right sidebar when looking at profiles for this application. Without this change, it would not show up at all for requests with the `queue` span.
2a79636
to
4f72d84
Compare
I've rebased this on top of current master without any other changes so as to incorporate the new CI job which is a requirement for merging. |
What does this PR do?
This PR tweaks the logic that decides if the profiler should collect the resource from an active trace to also consider the span type
proxy
, which is used when therequest_queuing
feature is in use in the rack instrumentation.Without this fix, the endpoint profiling feature (e.g. allowing customers to drill into their profiles by endpoint) does not work in combination with
request_queuing
, and the feature is hidden in the profiler UX.Motivation:
Make sure that customers that enable
request_queuing
are still able to look at their profiles per-endpoint.Additional Notes:
N/A
How to test the change?
The change includes test coverage. If you're interested in testing it out with a real http app, you can do so by enabling the
request_queuing
feature:and then perform a request to the app including the
X-Request-Start
header:This will generate a
queue
span, and with this change, the endpoint will show up in the right sidebar when looking at profiles for this application. Without this change, it would not show up at all for requests with thequeue
span.For Datadog employees:
credentials of any kind, I've requested a review from
@DataDog/security-design-and-guidance
.