[PROF-10275] Enable crashtracking telemetry by default when profiler is enabled #3816
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…is enabled
**What does this PR do?**
This PR enables the crashtracking telemetry feature by default when the
profiler is enabled.
This feature can be disabled using the
`DD_PROFILING_EXPERIMENTAL_CRASH_TRACKING_ENABLED` environment variable
or the `c.profiling.advanced.experimental_crash_tracking_enabled`
setting via code.
This setting is not very well-named, as the feature is no longer
experimental. But as we're actually considering separating crashtracking
from profiling, I decided to leave the current setting in place until we
can decide where this is going to live, since that's going to influence
where the new setting without "experimental" on its name should land.
**Motivation:**
Crashtracking allows us to identify issues that may otherwise go
unnoticed. We've been deploying it on other Datadog libraries with great
success so far.
**Additional Notes:**
We've had configurations running with crashtracking enabled on our usual
validation environments + almost all (1 remaining!) internal Ruby apps
also has been running with this feature.
We've not seen any noticeable impact for enabling this feature.
In fact, now that it's going to be the default, I'll go ahead and remove
the separate configurations we had for testing it.
**How to test the change?**
The following snippet starts a Ruby instance with profiling, and crashes
it immediately:
```bash
DD_PROFILING_ENABLED=true bundle exec ddprofrb exec ruby -e 'Process.kill("SEGV", Process.pid)'
```
You should see an error report submitted to the agent.
github-actions
bot
added
core
BenchmarksBenchmark execution time: 2024-07-31 10:22:06 Comparing candidate commit c686714 in PR branch Found 0 performance improvements and 1 performance regressions! Performance is the same for 9 metrics, 2 unstable metrics. scenario:Tracing.log_correlation
|
p-datadog
approved these changes
Jul 31, 2024
|
The one CI failure is being tracked separately and is unrelated to this PR (it's affecting all PRs for the past ~2 days). I'm going to go ahead and merge this one in! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
This PR enables the crashtracking telemetry feature by default when the profiler is enabled.
This feature can be disabled using the
DD_PROFILING_EXPERIMENTAL_CRASH_TRACKING_ENABLEDenvironment variable or thec.profiling.advanced.experimental_crash_tracking_enabledsetting via code.This setting is not very well-named, as the feature is no longer experimental. But as we're actually considering separating crashtracking from profiling, I decided to leave the current setting in place until we can decide where this is going to live, since that's going to influence where the new setting without "experimental" on its name should land.
Motivation:
Crashtracking allows us to identify issues that may otherwise go unnoticed. We've been deploying it on other Datadog libraries with great success so far.
Additional Notes:
We've had configurations running with crashtracking enabled on our usual validation environments + almost all (1 remaining!) internal Ruby apps also has been running with this feature.
We've not seen any noticeable impact for enabling this feature.
In fact, now that it's going to be the default, I'll go ahead and remove the separate configurations we had for testing it.
How to test the change?
The following snippet starts a Ruby instance with profiling, and crashes it immediately:
You should see an error report submitted to the agent.