Skip to content
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

profiler: support reconfiguring execution tracing at runtime #1978

Merged
merged 3 commits into from
May 10, 2023

Conversation

nsrip-dd
Copy link
Contributor

What does this PR do?

Have the profiler check the execution tracing configuration environment
variables at the beginning of each profiling cycle. That way, the environment
variables can be updated at run-time.

Motivation

Give initial users the flexibility to, for example, increase collection
frequency during periods where they suspect a performance issue is happening,
without requiring us to commit to a public interface for triggering or
reconfiguring trace collection.

Describe how to test/QA your changes

TODO. The existing tests pass. Perhaps worth adding an additional test to see
if updating the configuration works.

Reviewer's Checklist

  • Changed code has unit tests for its functionality.
  • If this interacts with the agent in a new way, a system test has been added.

Sorry, something went wrong.

Have the profiler check the execution tracing configuration environment
variables at the beginning of each profiling cycle. That way, the
environment variables can be updated at run-time. This will give initial
users the flexibility to, for example, increase collection frequency
during periods where they suspect a performance issue is happening,
without requiring us to commit to a public interface for triggering or
reconfiguring trace collection.
@pr-commenter
Copy link

pr-commenter bot commented May 10, 2023

Benchmarks

Comparing candidate commit bd4006c in PR branch nick.ripley/check-exectrace-config-frequently with baseline commit d2e0f49 in branch main.

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

Copy link
Member

@felixge felixge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Having a test would be nice, but not critical.

@nsrip-dd nsrip-dd marked this pull request as ready for review May 10, 2023 18:42
@nsrip-dd nsrip-dd requested a review from a team as a code owner May 10, 2023 18:42
@nsrip-dd nsrip-dd merged commit 3d9bf40 into main May 10, 2023
@nsrip-dd nsrip-dd deleted the nick.ripley/check-exectrace-config-frequently branch May 10, 2023 19:13
nsrip-dd added a commit that referenced this pull request May 24, 2023
go_execution_trace_enabled indicates whether execution tracing is
enabled, to distinguish between missing a trace because we don't collect
them every profiling cycle from missing a trace because the feature
isn't turned on.

While we're here, add these extra tracing tags to the batch object
that's built during the profiling cycle. We can't safely read the
execution trace config during the uploading, because it can be modified
concurrently by the profiler after #1978. It makes more sense to have
the profiler add all the needed information, which it can do safely, so
that the upload step can just deal with uploading.
katiehockman pushed a commit that referenced this pull request Jun 6, 2023
Have the profiler check the execution tracing configuration environment
variables at the beginning of each profiling cycle. That way, the
environment variables can be updated at run-time. This will give initial
users the flexibility to, for example, increase collection frequency
during periods where they suspect a performance issue is happening,
without requiring us to commit to a public interface for triggering or
reconfiguring trace collection.
nsrip-dd added a commit that referenced this pull request Jun 9, 2023
…1997)

Add a _dd.profiler.go_execution_trace_enabled tag to uploaded profiles.
Indicate whether execution tracing is enabled, to distinguish between missing a
trace because we don't collect them every profiling cycle from missing a trace
because the feature isn't turned on.

While we're here, add these extra tracing tags to the batch object
that's built during the profiling cycle. We can't safely read the
execution trace config during the uploading, because it can be modified
concurrently by the profiler after #1978. It makes more sense to have
the profiler add all the needed information, which it can do safely, so
that the upload step can just deal with uploading.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants