-
Notifications
You must be signed in to change notification settings - Fork 453
profiling: store trace endpoint in profiling events #2573
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
Conversation
e6ba01c
to
ed6a6b7
Compare
ed6a6b7
to
ded77b9
Compare
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.
This seems reasonable to me, but I'm definitely not a Python person.
ded77b9
to
33a1f8d
Compare
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.
Just a question, otherwise LGTM
@@ -346,6 +349,8 @@ | |||
thread_native_id=123987, | |||
thread_name="MainThread", | |||
trace_id=1322219321, | |||
trace_resource="notme", | |||
trace_type="sql", |
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.
Is this and the one below intentional or should have been SpanTypes.SQL.value
?
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.
Whatever. I mean both works and are valid here.
What we want is that if it's not SpanTypes.WEB
we don't store any trace_resource, so it being the "SQL" span type or the customer sql
, it must be the same behaviour :)
self, event # type: lock.LockEventBase | ||
): | ||
if event.trace_type == ext.SpanTypes.WEB.value: | ||
trace_resource = self._none_to_str(event.trace_resource) |
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.
there is likely an edge case with a few integrations where we don't set the resource until after the request has finished.
Pylons does this, not sure how many others, but could imagine if we don't get the resource before creating the span, could still be a race condition on whether we have it or not
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.
Right, though I am not sure this should block this PR?
That sounds like it's something we want to "improve" as possible in integrations.
This extends the previous behavior of TraceIdentifiers::Ddtrace to also return the root span resource, which will be used to enable aggregation-by-endpoint functionality in the profiler. Due to PII concerns (as explained in the comments), we start with a rather conservative filter of only allowing HTTP::TYPE_INBOUND traces. I took some inspiration from the similar implementation for Python (<DataDog/dd-trace-py#2573>) although I still need to validate with the wider team that the current filtering approach is reasonable for Ruby tracing as well.
This extends the previous behavior of TraceIdentifiers::Ddtrace to also return the root span resource, which will be used to enable aggregation-by-endpoint functionality in the profiler. Due to PII concerns (as explained in the comments), we start with a rather conservative filter of only allowing HTTP::TYPE_INBOUND traces. I took some inspiration from the similar implementation for Python (<DataDog/dd-trace-py#2573>) although I still need to validate with the wider team that the current filtering approach is reasonable for Ruby tracing as well.
feat(profiling): store trace resource in profiling events
feat(pprof): export trace resource in profiles