fix(tracer): don't activate runtime metrics v1 if otel runtime metrics are enabled

[anna-git]

Following #4803, fixes dual-emission when both DD_RUNTIME_METRICS_ENABLED=true and DD_METRICS_OTEL_ENABLED=true are set: the legacy v1 runtime metrics shouldn't start.

Fix: Pre-compute otelRuntimeMetricsShouldBeEnabled in config (option.go) and add a !otelRuntimeMetricsShouldBeEnabled guard around the legacy goroutine in newTracer().

Testing:

• TestTracerRuntimeMetrics (all subtests) pass
• Validated against system-tests PR #6857 (OTLP_RUNTIME_METRICS scenario): test_otel_metrics_are_present_and_attributed and test_dd_metrics_are_absent both pass

🤖 Generated with Claude Code

[datadog-datadog-prod-us1]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 62.78% (-3.66%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: b0ae9bf | Docs | Datadog PR Page | Give us feedback!}

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-06-30 12:07:20

Comparing candidate commit b0ae9bf in PR branch anna.yafi/fix-otel-runtime-metrics-dual-emission with baseline commit 1c9a3b0 in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 321 metrics, 2 unstable metrics, 1 flaky benchmarks without significant changes.

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 ----------------------------------'

Known flaky benchmarks

These benchmarks are marked as flaky and will not trigger a failure. Modify FLAKY_BENCHMARKS_REGEX to control which benchmarks are marked as flaky.

Known flaky benchmarks without significant changes:

• scenario:BenchmarkOTLPTraceWriterFlush

[darccio]

LGTM but I think we are missing a test here. This is a regression risk, a unit test would be a safety addition. It could be TestTracerLegacyRuntimeMetricsSuppressedWhenOtelActive in metrics_otel_test.go, setting DD_RUNTIME_METRICS_ENABLED=true + DD_METRICS_OTEL_ENABLED=true, call withTestHooks, call newTracer, and assert the "Runtime metrics enabled." debug log is absent (same pattern as the on subtest in TestTracerRuntimeMetrics).

[anna-git]

LGTM but I think we are missing a test here. This is a regression risk, a unit test would be a safety addition. It could be TestTracerLegacyRuntimeMetricsSuppressedWhenOtelActive in metrics_otel_test.go, setting DD_RUNTIME_METRICS_ENABLED=true + DD_METRICS_OTEL_ENABLED=true, call withTestHooks, call newTracer, and assert the "Runtime metrics enabled." debug log is absent (same pattern as the on subtest in TestTracerRuntimeMetrics).

Good point! Added a test that asserts legacy runtime metrics aren't enabled when OTel is active (b0ae9bf), this sets both flags, installs stub hooks, calls newTracer, and asserts legacy runtime metrics aren't started when OTel is active reading logs and boolean.

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-06-30 12:09:42 UTC ℹ️ Start processing command devflow:merge

---

2026-06-30 12:09:51 UTC ℹ️ MergeQueue: waiting for PR to be ready

This pull request is not mergeable according to GitHub. Common reasons include pending required checks, missing approvals, or merge conflicts — but it could also be blocked by other repository rules or settings.
It will be added to the queue as soon as checks pass and/or get approvals. View in MergeQueue UI.
Note: if you pushed new commits since the last approval, you may need additional approval.
You can remove it from the waiting list with /remove command.

---

2026-06-30 16:24:17 UTC ⚠️ MergeQueue: This merge request was unqueued

devflow unqueued this merge request: It did not become mergeable within the expected time

[zacharycmontoya]

LGTM requirements wise

[anna-git]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-06-30 16:30:30 UTC ℹ️ Start processing command /merge

---

2026-06-30 16:30:35 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in main is approximately 19m (p90).

---

2026-06-30 16:36:19 UTC ℹ️ MergeQueue: Readding this merge request to the queue because another merge request processed with yours failed. No action is needed from your side.

---

2026-06-30 17:22:59 UTC ❌ MergeQueue: The checks failed on this merge request

Tests failed on this commit ab3259f:

• System Tests
• Build weblog (graphql-go)

What to do next?

• Investigate the failures and when ready, re-add your pull request to the queue!
• If your PR checks are green, try to rebase/merge. It might be because the CI run is a bit old.
• Any question, go check the FAQ.

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-06-30 17:27:34 UTC ℹ️ Start processing command devflow:merge

---

2026-06-30 17:27:39 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in main is approximately 19m (p90).

---

2026-06-30 17:44:56 UTC ℹ️ MergeQueue: This merge request was merged