Skip to content

Comments

Update document v2.29.0#5384

Open
dd-apm-ecosystems-autobot[bot] wants to merge 237 commits intoreleasefrom
update-document-v2.29.0
Open

Update document v2.29.0#5384
dd-apm-ecosystems-autobot[bot] wants to merge 237 commits intoreleasefrom
update-document-v2.29.0

Conversation

@dd-apm-ecosystems-autobot
Copy link
Contributor

This is an auto-generated PR to update documentation from here. Please merge (with a merge commit) when ready.\n\nTo resolve conflicts:\nbash\ngit merge release\ngit checkout --ours ..

r1viollet and others added 30 commits January 21, 2026 14:28
The idea is to delay the time at which we record object ids.
Once we are outside of the allocation code path, we can request the object ID.
- Avoid scheduling many postponed jobs
This fixes some of the issues we had with accuracy
Also I suspect that this has less overhead
- Avoid re-entrancy based on Ivo's comments
Although some of this code is dead code on legacy Rubies, always
compiling it in means less ifdefs spread throughout and it helps
keep the code focused on modern rubies, rather than on legacy ones.
This check is already covered by
`heap_recorder->active_recording != NULL` (they're set and unset
together).
This makes it easier to use this in tests.
…lector

This moves the logic closer to the heap profiler and helps focus the
CpuAndWallTimeWorker on what (triggering or not) and not why (doesn't
care?).
This API only became available after I rebased.
This reverts commit e153759.

(Avoid touching CHANGELOG for nicer diff)
…is needed

This will replace the more heavy-handed query in
`thread_context_collector_heap_pending_buffer_pressure`.
…filer directly

This avoids other parts of the profiler needing to care about this --
they only need to care to run the `after_sample` callback.
…ons directly

We no longer need to ask other parts of the code to raise instead :)
This probably needs adjusting for non-4.0 rubies, will do it as
a separate pass.
In the future we may end up using the deferred recording for legacy
rubies as well, so might as well lay the groundwork.
y9v and others added 8 commits February 18, 2026 17:04
Add `appsec.api_security.missing_route` telemetry
* Add process and container id following java

* turns out process tags should only be added to process discovery when enabled per the system tests.

* Address review comments and add more tests

* Refactor tests

* Fix CI errors.
…ns/runs/22191009051 (#5366)

Co-authored-by: dd-apm-ecosystems-autobot[bot] <214617597+dd-apm-ecosystems-autobot[bot]@users.noreply.github.com>
@dd-apm-ecosystems-autobot dd-apm-ecosystems-autobot bot added the docs Involves documentation label Feb 20, 2026
@dd-apm-ecosystems-autobot dd-apm-ecosystems-autobot bot requested review from a team as code owners February 20, 2026 15:08
@dd-apm-ecosystems-autobot dd-apm-ecosystems-autobot bot requested review from leoromanovsky, mabdinur and sameerank and removed request for a team February 20, 2026 15:08
@github-actions
Copy link

👋 Hey @DataDog/ruby-guild, please fill "Change log entry" section in the pull request description.

If changes need to be present in CHANGELOG.md you can state it this way

**Change log entry**

Yes. A brief summary to be placed into the CHANGELOG.md

(possible answers Yes/Yep/Yeah)

Or you can opt out like that

**Change log entry**

None.

(possible answers No/Nope/None)

Visited at: 2026-02-20 15:08:37 UTC

@github-actions github-actions bot added core Involves Datadog core libraries integrations Involves tracing integrations profiling Involves Datadog profiling appsec Application Security monitoring product tracing labels Feb 20, 2026
@pr-commenter
Copy link

pr-commenter bot commented Feb 20, 2026

Benchmarks

Benchmark execution time: 2026-02-20 15:38:42

Comparing candidate commit 799b3dc in PR branch update-document-v2.29.0 with baseline commit 065545f in branch release.

Found 2 performance improvements and 3 performance regressions! Performance is the same for 39 metrics, 2 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:line instrumentation - targeted

  • 🟥 throughput [-16915.539op/s; -16421.203op/s] or [-11.404%; -11.071%]

scenario:line instrumentation - untargeted

  • 🟥 throughput [-23071.762op/s; -22935.469op/s] or [-39.235%; -39.003%]

scenario:method instrumentation

  • 🟥 throughput [-17464.879op/s; -16663.455op/s] or [-10.164%; -9.698%]

scenario:tracing - Propagation - Datadog

  • 🟩 throughput [+2915.556op/s; +3012.450op/s] or [+9.832%; +10.159%]

scenario:tracing - Tracing.log_correlation

  • 🟩 throughput [+8949.610op/s; +9317.805op/s] or [+8.700%; +9.058%]

This enables support for [Endpoint Observability](https://docs.datadoghq.com/internal_developer_portal/software_catalog/endpoints/).

It is **not** possible to change the unified tracer option in a `Datadog.configure` block.
This limitation will be removed in `datadog` 3.0.0.
Copy link
Contributor

Choose a reason for hiding this comment

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

I know this is preexisting language, but instead of listing when this will be removed, is it possible to update this warning after datadog 3.0.0.0?

Suggested change
This limitation will be removed in `datadog` 3.0.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

appsec Application Security monitoring product core Involves Datadog core libraries docs Involves documentation integrations Involves tracing integrations profiling Involves Datadog profiling tracing

Projects

None yet

Development

Successfully merging this pull request may close these issues.