-
Notifications
You must be signed in to change notification settings - Fork 418
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
feat(onboarding): early exit conditions in lib-injection #9323
Conversation
Datadog ReportBranch report: ✅ 0 Failed, 115914 Passed, 59925 Skipped, 2h 49m 50.84s Total duration (6h 10m 30.05s time saved) |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #9323 +/- ##
===========================================
- Coverage 75.89% 10.27% -65.62%
===========================================
Files 1315 1285 -30
Lines 124966 123127 -1839
===========================================
- Hits 94837 12650 -82187
- Misses 30129 110477 +80348 ☔ View full report in Codecov by Sentry. |
BenchmarksBenchmark execution time: 2024-06-11 14:03:03 Comparing candidate commit 43bdbc3 in PR branch Found 1 performance improvements and 0 performance regressions! Performance is the same for 220 metrics, 9 unstable metrics. scenario:otelspan-start
|
8f51944
to
4f47c1b
Compare
f94cf14
to
c3f9073
Compare
…etric name changes, adding override tag to complete event
Pull Request is not mergeable
Co-authored-by: Zachary Groves <[email protected]>
Co-authored-by: Zachary Groves <[email protected]>
This pull request adds "guardrails" to the "library injection" process. These are early exit conditions from the instrumentation process intended to avoid sending any traces when undefined behavior is likely. The code makes this determination on the basis of software versions present in the application environment, both of Python packages and the Python runtime itself. The biggest risk here is that instrumentation is disabled when it's not intended to be. I think existing tests in `tests/lib-injection` cover this pretty well. There's a new test added that verifies instrumentation was cancelled when an unsupported package version is present. Contains changes from #9418 Related RFC: "[RFC] One Step Guardrails" ## Checklist - [x] minimum package version checks - [x] Testing - [x] replace envvars with inject_force - [x] figure out what to use instead of pkg_resources - [x] replace local file path with `DD_TELEMETRY_FORWARDER_PATH` - [x] Change(s) are motivated and described in the PR description - [x] Testing strategy is described if automated tests are not included in the PR - [x] Risks are described (performance impact, potential for breakage, maintainability) - [x] Change is maintainable (easy to change, telemetry, documentation) - [x] [Library release note guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html) are followed or label `changelog/no-changelog` is set - [x] Documentation is included (in-code, generated user docs, [public corp docs](https://github.com/DataDog/documentation/)) - [x] Backport labels are set (if [applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)) - [x] If this PR changes the public interface, I've notified `@DataDog/apm-tees`. ## Reviewer Checklist - [x] Title is accurate - [x] All changes are related to the pull request's stated goal - [x] Description motivates each change - [x] Avoids breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes - [x] Testing strategy adequately addresses listed risks - [x] Change is maintainable (easy to change, telemetry, documentation) - [x] Release note makes sense to a user of the library - [x] Author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment - [x] Backport labels are set in a manner that is consistent with the [release branch maintenance policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting) --------- Co-authored-by: Emmett Butler <[email protected]> Co-authored-by: Emmett Butler <[email protected]> (cherry picked from commit 0c38e09)
…10] (#9512) Backport 0c38e09 from #9323 to 2.10. This pull request adds "guardrails" to the "library injection" process. These are early exit conditions from the instrumentation process intended to avoid sending any traces when undefined behavior is likely. The code makes this determination on the basis of software versions present in the application environment, both of Python packages and the Python runtime itself. The biggest risk here is that instrumentation is disabled when it's not intended to be. I think existing tests in `tests/lib-injection` cover this pretty well. There's a new test added that verifies instrumentation was cancelled when an unsupported package version is present. Contains changes from #9418 Related RFC: "[RFC] One Step Guardrails" ## Checklist - [x] minimum package version checks - [x] Testing - [x] replace envvars with inject_force - [x] figure out what to use instead of pkg_resources - [x] replace local file path with `DD_TELEMETRY_FORWARDER_PATH` - [x] Change(s) are motivated and described in the PR description - [x] Testing strategy is described if automated tests are not included in the PR - [x] Risks are described (performance impact, potential for breakage, maintainability) - [x] Change is maintainable (easy to change, telemetry, documentation) - [x] [Library release note guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html) are followed or label `changelog/no-changelog` is set - [x] Documentation is included (in-code, generated user docs, [public corp docs](https://github.com/DataDog/documentation/)) - [x] Backport labels are set (if [applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)) - [x] If this PR changes the public interface, I've notified `@DataDog/apm-tees`. ## Reviewer Checklist - [x] Title is accurate - [x] All changes are related to the pull request's stated goal - [x] Description motivates each change - [x] Avoids breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes - [x] Testing strategy adequately addresses listed risks - [x] Change is maintainable (easy to change, telemetry, documentation) - [x] Release note makes sense to a user of the library - [x] Author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment - [x] Backport labels are set in a manner that is consistent with the [release branch maintenance policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting) Co-authored-by: Zachary Groves <[email protected]>
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-2.9 2.9
# Navigate to the new working tree
cd .worktrees/backport-2.9
# Create a new branch
git switch --create backport-9323-to-2.9
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 0c38e09db92cceedc8affff4a217357fc2a1bcac
# Push it to GitHub
git push --set-upstream origin backport-9323-to-2.9
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-2.9 Then, create a pull request where the |
This pull request adds "guardrails" to the "library injection" process. These are early exit conditions from the instrumentation process intended to avoid sending any traces when undefined behavior is likely. The code makes this determination on the basis of software versions present in the application environment, both of Python packages and the Python runtime itself. The biggest risk here is that instrumentation is disabled when it's not intended to be. I think existing tests in `tests/lib-injection` cover this pretty well. There's a new test added that verifies instrumentation was cancelled when an unsupported package version is present. Contains changes from #9418 Related RFC: "[RFC] One Step Guardrails" - [x] minimum package version checks - [x] Testing - [x] replace envvars with inject_force - [x] figure out what to use instead of pkg_resources - [x] replace local file path with `DD_TELEMETRY_FORWARDER_PATH` - [x] Change(s) are motivated and described in the PR description - [x] Testing strategy is described if automated tests are not included in the PR - [x] Risks are described (performance impact, potential for breakage, maintainability) - [x] Change is maintainable (easy to change, telemetry, documentation) - [x] [Library release note guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html) are followed or label `changelog/no-changelog` is set - [x] Documentation is included (in-code, generated user docs, [public corp docs](https://github.com/DataDog/documentation/)) - [x] Backport labels are set (if [applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)) - [x] If this PR changes the public interface, I've notified `@DataDog/apm-tees`. - [x] Title is accurate - [x] All changes are related to the pull request's stated goal - [x] Description motivates each change - [x] Avoids breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes - [x] Testing strategy adequately addresses listed risks - [x] Change is maintainable (easy to change, telemetry, documentation) - [x] Release note makes sense to a user of the library - [x] Author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment - [x] Backport labels are set in a manner that is consistent with the [release branch maintenance policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting) --------- Co-authored-by: Emmett Butler <[email protected]> Co-authored-by: Emmett Butler <[email protected]> (cherry picked from commit 0c38e09)
This pull request adds "guardrails" to the "library injection" process. These are early exit conditions from the instrumentation process intended to avoid sending any traces when undefined behavior is likely. The code makes this determination on the basis of software versions present in the application environment, both of Python packages and the Python runtime itself.
The biggest risk here is that instrumentation is disabled when it's not intended to be. I think existing tests in
tests/lib-injection
cover this pretty well. There's a new test added that verifies instrumentation was cancelled when an unsupported package version is present.Contains changes from #9418
Related RFC: "[RFC] One Step Guardrails"
Checklist
DD_TELEMETRY_FORWARDER_PATH
changelog/no-changelog
is set@DataDog/apm-tees
.Reviewer Checklist