enable process tags to true by default

[wantsui]

What does this PR do?

Sets DD_EXPERIMENTAL_PROPAGATE_PROCESS_TAGS_ENABLED to true so that the process tags are always collected by default. (This will support other initiatives)

Motivation:

The other tracers are also doing this:

• Enable process tags collection by default dd-trace-java#9510
• feat: enable process tags by default dd-trace-go#4008
• feat(process_tags): enable process tags by default dd-trace-py#16743

Change log entry

Yes. Enables process tags for Tracing, Database Monitoring, Data Streams Monitoring, Profiling, Runtime Metrics, Process Discovery, Remote Configuration, Telemetry, Dynamic Instrumentation, and CrashTracking.

Additional Notes:

Yes. I'm currently trying to understand the expectations around:

• the other DBM related setting: DD_DBM_INJECT_SQL_BASEHASH - what do we do with this?
  - Answer: From checking with the team, we'll leave this DBM behavior alone.
• if we're going to set this to "true", I think DD_EXPERIMENTAL_PROPAGATE_PROCESS_TAGS_ENABLED is a poor name for the config to override it so I'll ask if there should be an alias since we'll likely want to document this new setting.
  - Answer: From checking with the rest of my team working on this feature, we'll leave it as DD_EXPERIMENTAL_PROPAGATE_PROCESS_TAGS_ENABLED for now. There are no plans to alias it.

How to test the change?

When I made the other PRs, I already tested the feature by enabling it and seeing the results. The CI should pass the same way, and if not I will review.

[github-actions]

Thank you for updating Change log entry section 👏

^{Visited at: 2026-03-09 23:03:42 UTC}

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-03-13 21:16:34

Comparing candidate commit 8e27c3e in PR branch enable-process-tags with baseline commit 25f2155 in branch master.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 46 metrics, 0 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 ----------------------------------'

[datadog-prod-us1-6]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
• Patch Coverage: 70.73%
• Overall Coverage: 95.14% (-0.01%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 8e27c3e | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback!}

[ivoanjo]

Left a few notes!

if we're going to set this to "true", I think DD_EXPERIMENTAL_PROPAGATE_PROCESS_TAGS_ENABLED is a poor name for the config to override it so I'll ask if there should be an alias since we'll likely want to document this new setting.

+1 on this one -- if this is no longer experimental we should probably deprecate the old flag (but not a blocker for this PR)

[ivoanjo]

👍 Looks reasonable! Left one last round of suggestions

[ivoanjo]

Spotted a few more weird things!