Skip to content

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

Merged
merged 4 commits into from
Jun 30, 2021

Conversation

jd
Copy link
Contributor

@jd jd commented Jun 22, 2021

feat(profiling): store trace resource in profiling events

feat(pprof): export trace resource in profiles

@jd jd requested a review from a team as a code owner June 22, 2021 16:08
@jd jd force-pushed the profiling/embed-resource-name branch from e6ba01c to ed6a6b7 Compare June 22, 2021 16:13
@jd jd added the changelog/no-changelog A changelog entry is not required for this PR. label Jun 22, 2021
@jd jd force-pushed the profiling/embed-resource-name branch from ed6a6b7 to ded77b9 Compare June 22, 2021 16:18
@jd jd requested a review from mar-kolya June 22, 2021 16:24
Copy link
Contributor

@mar-kolya mar-kolya left a 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.

Yun-Kim
Yun-Kim previously approved these changes Jun 23, 2021
@jd jd added the manual merge Do not automatically merge label Jun 24, 2021
@jd jd force-pushed the profiling/embed-resource-name branch from ded77b9 to 33a1f8d Compare June 24, 2021 12:00
@jd jd removed the manual merge Do not automatically merge label Jun 24, 2021
Copy link
Contributor

@P403n1x87 P403n1x87 left a 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",
Copy link
Contributor

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?

Copy link
Contributor Author

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)
Copy link
Member

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

Copy link
Contributor Author

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.

@mergify mergify bot merged commit 72e00b3 into DataDog:master Jun 30, 2021
ivoanjo added a commit to DataDog/dd-trace-rb that referenced this pull request Jul 15, 2021
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.
ivoanjo added a commit to DataDog/dd-trace-rb that referenced this pull request Jul 15, 2021
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog/no-changelog A changelog entry is not required for this PR.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants