Skip to content

Read container tags hash from agent#7893

Merged
vandonr merged 17 commits intomasterfrom
vandonr/process3
Feb 3, 2026
Merged

Read container tags hash from agent#7893
vandonr merged 17 commits intomasterfrom
vandonr/process3

Conversation

@vandonr
Copy link
Contributor

@vandonr vandonr commented Dec 3, 2025

Summary of changes

same as DataDog/dd-trace-java#9156

  • send container ID to the agent with feature discovery requests
  • get back the container tags hash and store it

This hash is meant to be matched in the backend with the actual container tags, with the advantage that :

  • it's less cardinality than container ID
  • it's smaller than propagating th tag values themselves

related RFC: https://docs.google.com/document/d/15GtNOKGBCt6Dc-HsDNnMmCdZwhewFQx8yUlI9in5n3M

Implementation details

Test coverage

Other details

@vandonr vandonr requested a review from a team as a code owner December 3, 2025 09:26
/// <summary>
/// Gets or sets the container tags hash received from the agent, used by DBM/DSM
/// </summary>
public static string ContainerTagsHash { get; set; }
Copy link
Member

Choose a reason for hiding this comment

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

AFAICT, this isn't actually used anywhere? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yet 😏
I could use it in the same PR, but I wanted to do baby steps. It's gonna be used in DSM and DBM injection

Copy link
Contributor Author

Choose a reason for hiding this comment

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

see #8061

@datadog-datadog-prod-us1

This comment has been minimized.

@dd-trace-dotnet-ci-bot
Copy link

dd-trace-dotnet-ci-bot bot commented Dec 3, 2025

Execution-Time Benchmarks Report ⏱️

Execution-time results for samples comparing This PR (7893) and master.

✅ No regressions detected - check the details below

Full Metrics Comparison

FakeDbCommand

Metric Master (Mean ± 95% CI) Current (Mean ± 95% CI) Change Status
.NET Framework 4.8 - Baseline
duration72.83 ± (73.01 - 73.46) ms73.88 ± (73.97 - 74.29) ms+1.4%✅⬆️
.NET Framework 4.8 - Bailout
duration77.41 ± (77.37 - 77.72) ms79.22 ± (79.15 - 79.57) ms+2.3%✅⬆️
.NET Framework 4.8 - CallTarget+Inlining+NGEN
duration1062.00 ± (1061.98 - 1068.49) ms1075.71 ± (1079.09 - 1086.99) ms+1.3%✅⬆️
.NET Core 3.1 - Baseline
process.internal_duration_ms22.77 ± (22.73 - 22.81) ms22.98 ± (22.92 - 23.03) ms+0.9%✅⬆️
process.time_to_main_ms86.57 ± (86.34 - 86.79) ms88.21 ± (87.98 - 88.45) ms+1.9%✅⬆️
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed10.95 ± (10.95 - 10.95) MB10.97 ± (10.96 - 10.97) MB+0.1%✅⬆️
runtime.dotnet.threads.count12 ± (12 - 12)12 ± (12 - 12)+0.0%
.NET Core 3.1 - Bailout
process.internal_duration_ms22.80 ± (22.76 - 22.85) ms22.88 ± (22.82 - 22.94) ms+0.3%✅⬆️
process.time_to_main_ms88.26 ± (88.04 - 88.49) ms89.35 ± (89.14 - 89.57) ms+1.2%✅⬆️
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed10.98 ± (10.98 - 10.99) MB11.00 ± (10.99 - 11.00) MB+0.1%✅⬆️
runtime.dotnet.threads.count13 ± (13 - 13)13 ± (13 - 13)+0.0%
.NET Core 3.1 - CallTarget+Inlining+NGEN
process.internal_duration_ms239.83 ± (236.05 - 243.62) ms244.05 ± (239.81 - 248.29) ms+1.8%✅⬆️
process.time_to_main_ms501.31 ± (500.56 - 502.06) ms510.06 ± (509.24 - 510.89) ms+1.7%✅⬆️
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed48.62 ± (48.60 - 48.64) MB48.59 ± (48.57 - 48.62) MB-0.1%
runtime.dotnet.threads.count28 ± (28 - 28)28 ± (28 - 28)-0.0%
.NET 6 - Baseline
process.internal_duration_ms21.37 ± (21.33 - 21.41) ms21.89 ± (21.85 - 21.94) ms+2.4%✅⬆️
process.time_to_main_ms74.18 ± (73.98 - 74.37) ms77.05 ± (76.86 - 77.25) ms+3.9%✅⬆️
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed10.65 ± (10.65 - 10.65) MB10.69 ± (10.69 - 10.70) MB+0.4%✅⬆️
runtime.dotnet.threads.count10 ± (10 - 10)10 ± (10 - 10)+0.0%
.NET 6 - Bailout
process.internal_duration_ms21.25 ± (21.21 - 21.28) ms21.70 ± (21.64 - 21.76) ms+2.1%✅⬆️
process.time_to_main_ms74.69 ± (74.51 - 74.87) ms77.28 ± (77.07 - 77.49) ms+3.5%✅⬆️
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed10.73 ± (10.72 - 10.74) MB10.79 ± (10.79 - 10.80) MB+0.6%✅⬆️
runtime.dotnet.threads.count11 ± (11 - 11)11 ± (11 - 11)+0.0%
.NET 6 - CallTarget+Inlining+NGEN
process.internal_duration_ms233.61 ± (228.47 - 238.75) ms240.69 ± (236.59 - 244.79) ms+3.0%✅⬆️
process.time_to_main_ms474.16 ± (473.21 - 475.11) ms483.99 ± (483.25 - 484.73) ms+2.1%✅⬆️
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed49.29 ± (49.25 - 49.32) MB49.31 ± (49.28 - 49.33) MB+0.0%✅⬆️
runtime.dotnet.threads.count28 ± (28 - 28)28 ± (28 - 28)+0.0%✅⬆️
.NET 8 - Baseline
process.internal_duration_ms19.42 ± (19.39 - 19.45) ms19.97 ± (19.93 - 20.01) ms+2.8%✅⬆️
process.time_to_main_ms72.68 ± (72.53 - 72.83) ms75.66 ± (75.48 - 75.85) ms+4.1%✅⬆️
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed7.71 ± (7.71 - 7.72) MB7.74 ± (7.73 - 7.75) MB+0.3%✅⬆️
runtime.dotnet.threads.count10 ± (10 - 10)10 ± (10 - 10)+0.0%
.NET 8 - Bailout
process.internal_duration_ms19.52 ± (19.47 - 19.56) ms20.05 ± (20.00 - 20.10) ms+2.7%✅⬆️
process.time_to_main_ms73.92 ± (73.77 - 74.06) ms76.74 ± (76.55 - 76.92) ms+3.8%✅⬆️
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed7.77 ± (7.76 - 7.78) MB7.78 ± (7.77 - 7.78) MB+0.1%✅⬆️
runtime.dotnet.threads.count11 ± (11 - 11)11 ± (11 - 11)+0.0%
.NET 8 - CallTarget+Inlining+NGEN
process.internal_duration_ms187.18 ± (186.33 - 188.02) ms190.97 ± (190.07 - 191.87) ms+2.0%✅⬆️
process.time_to_main_ms459.85 ± (458.72 - 460.97) ms471.31 ± (470.51 - 472.11) ms+2.5%✅⬆️
runtime.dotnet.exceptions.count0 ± (0 - 0)0 ± (0 - 0)+0.0%
runtime.dotnet.mem.committed36.78 ± (36.74 - 36.82) MB36.86 ± (36.80 - 36.92) MB+0.2%✅⬆️
runtime.dotnet.threads.count27 ± (27 - 27)27 ± (27 - 27)+0.1%✅⬆️

HttpMessageHandler

Metric Master (Mean ± 95% CI) Current (Mean ± 95% CI) Change Status
.NET Framework 4.8 - Baseline
duration198.10 ± (198.01 - 198.92) ms198.85 ± (199.02 - 199.94) ms+0.4%✅⬆️
.NET Framework 4.8 - Bailout
duration201.40 ± (200.99 - 201.68) ms202.77 ± (202.42 - 203.24) ms+0.7%✅⬆️
.NET Framework 4.8 - CallTarget+Inlining+NGEN
duration1158.77 ± (1160.78 - 1168.50) ms1162.49 ± (1161.94 - 1168.40) ms+0.3%✅⬆️
.NET Core 3.1 - Baseline
process.internal_duration_ms191.26 ± (190.89 - 191.64) ms192.83 ± (192.40 - 193.26) ms+0.8%✅⬆️
process.time_to_main_ms82.97 ± (82.69 - 83.26) ms83.44 ± (83.21 - 83.66) ms+0.6%✅⬆️
runtime.dotnet.exceptions.count3 ± (3 - 3)3 ± (3 - 3)+0.0%
runtime.dotnet.mem.committed16.18 ± (16.16 - 16.21) MB16.19 ± (16.17 - 16.21) MB+0.0%✅⬆️
runtime.dotnet.threads.count20 ± (20 - 20)20 ± (20 - 20)-0.0%
.NET Core 3.1 - Bailout
process.internal_duration_ms190.53 ± (190.13 - 190.92) ms192.42 ± (191.94 - 192.90) ms+1.0%✅⬆️
process.time_to_main_ms84.20 ± (84.00 - 84.39) ms84.66 ± (84.43 - 84.90) ms+0.6%✅⬆️
runtime.dotnet.exceptions.count3 ± (3 - 3)3 ± (3 - 3)+0.0%
runtime.dotnet.mem.committed16.27 ± (16.24 - 16.30) MB16.15 ± (16.13 - 16.18) MB-0.7%
runtime.dotnet.threads.count21 ± (21 - 21)21 ± (20 - 21)-0.4%
.NET Core 3.1 - CallTarget+Inlining+NGEN
process.internal_duration_ms434.96 ± (431.98 - 437.95) ms421.33 ± (417.69 - 424.97) ms-3.1%
process.time_to_main_ms491.00 ± (490.19 - 491.82) ms491.94 ± (491.22 - 492.67) ms+0.2%✅⬆️
runtime.dotnet.exceptions.count3 ± (3 - 3)3 ± (3 - 3)+0.0%
runtime.dotnet.mem.committed59.06 ± (58.94 - 59.18) MB59.23 ± (59.11 - 59.35) MB+0.3%✅⬆️
runtime.dotnet.threads.count29 ± (29 - 30)29 ± (29 - 30)+0.1%✅⬆️
.NET 6 - Baseline
process.internal_duration_ms195.58 ± (195.20 - 195.96) ms197.08 ± (196.60 - 197.56) ms+0.8%✅⬆️
process.time_to_main_ms71.78 ± (71.60 - 71.97) ms72.44 ± (72.23 - 72.64) ms+0.9%✅⬆️
runtime.dotnet.exceptions.count4 ± (4 - 4)4 ± (4 - 4)+0.0%
runtime.dotnet.mem.committed16.43 ± (16.40 - 16.47) MB16.39 ± (16.37 - 16.41) MB-0.3%
runtime.dotnet.threads.count19 ± (19 - 19)19 ± (19 - 19)+0.1%✅⬆️
.NET 6 - Bailout
process.internal_duration_ms195.68 ± (195.26 - 196.09) ms195.90 ± (195.48 - 196.32) ms+0.1%✅⬆️
process.time_to_main_ms73.03 ± (72.88 - 73.18) ms73.29 ± (73.13 - 73.45) ms+0.4%✅⬆️
runtime.dotnet.exceptions.count4 ± (4 - 4)4 ± (4 - 4)+0.0%
runtime.dotnet.mem.committed16.44 ± (16.41 - 16.47) MB16.38 ± (16.36 - 16.41) MB-0.3%
runtime.dotnet.threads.count20 ± (20 - 20)20 ± (20 - 20)-0.3%
.NET 6 - CallTarget+Inlining+NGEN
process.internal_duration_ms448.62 ± (445.37 - 451.87) ms450.47 ± (447.28 - 453.66) ms+0.4%✅⬆️
process.time_to_main_ms468.54 ± (467.89 - 469.18) ms471.24 ± (470.51 - 471.98) ms+0.6%✅⬆️
runtime.dotnet.exceptions.count4 ± (4 - 4)4 ± (4 - 4)+0.0%
runtime.dotnet.mem.committed59.13 ± (58.99 - 59.27) MB58.95 ± (58.81 - 59.09) MB-0.3%
runtime.dotnet.threads.count29 ± (29 - 29)29 ± (29 - 29)+0.1%✅⬆️
.NET 8 - Baseline
process.internal_duration_ms195.30 ± (194.91 - 195.70) ms194.93 ± (194.44 - 195.42) ms-0.2%
process.time_to_main_ms71.91 ± (71.73 - 72.09) ms71.89 ± (71.69 - 72.09) ms-0.0%
runtime.dotnet.exceptions.count4 ± (4 - 4)4 ± (4 - 4)+0.0%
runtime.dotnet.mem.committed11.80 ± (11.78 - 11.82) MB11.80 ± (11.79 - 11.82) MB+0.0%✅⬆️
runtime.dotnet.threads.count18 ± (18 - 18)18 ± (18 - 18)-0.1%
.NET 8 - Bailout
process.internal_duration_ms193.95 ± (193.64 - 194.26) ms193.62 ± (193.26 - 193.98) ms-0.2%
process.time_to_main_ms72.74 ± (72.63 - 72.86) ms72.96 ± (72.82 - 73.11) ms+0.3%✅⬆️
runtime.dotnet.exceptions.count4 ± (4 - 4)4 ± (4 - 4)+0.0%
runtime.dotnet.mem.committed11.87 ± (11.84 - 11.89) MB11.81 ± (11.78 - 11.83) MB-0.5%
runtime.dotnet.threads.count19 ± (19 - 19)19 ± (19 - 19)+0.3%✅⬆️
.NET 8 - CallTarget+Inlining+NGEN
process.internal_duration_ms373.85 ± (372.32 - 375.39) ms375.34 ± (373.71 - 376.98) ms+0.4%✅⬆️
process.time_to_main_ms451.90 ± (451.01 - 452.78) ms455.47 ± (454.63 - 456.31) ms+0.8%✅⬆️
runtime.dotnet.exceptions.count4 ± (4 - 4)4 ± (4 - 4)+0.0%
runtime.dotnet.mem.committed48.38 ± (48.35 - 48.41) MB48.37 ± (48.33 - 48.40) MB-0.0%
runtime.dotnet.threads.count29 ± (29 - 29)29 ± (29 - 29)+0.2%✅⬆️
Comparison explanation

Execution-time benchmarks measure the whole time it takes to execute a program, and are intended to measure the one-off costs. Cases where the execution time results for the PR are worse than latest master results are highlighted in **red**. The following thresholds were used for comparing the execution times:

  • Welch test with statistical test for significance of 5%
  • Only results indicating a difference greater than 5% and 5 ms are considered.

Note that these results are based on a single point-in-time result for each branch. For full results, see the dashboard.

Graphs show the p99 interval based on the mean and StdDev of the test run, as well as the mean value of the run (shown as a diamond below the graph).

Duration charts
FakeDbCommand (.NET Framework 4.8)
gantt
    title Execution time (ms) FakeDbCommand (.NET Framework 4.8)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (7893) - mean (74ms)  : 72, 76
    master - mean (73ms)  : 70, 77

    section Bailout
    This PR (7893) - mean (79ms)  : 77, 82
    master - mean (78ms)  : 75, 80

    section CallTarget+Inlining+NGEN
    This PR (7893) - mean (1,083ms)  : 1025, 1141
    master - mean (1,065ms)  : 1022, 1109

Loading
FakeDbCommand (.NET Core 3.1)
gantt
    title Execution time (ms) FakeDbCommand (.NET Core 3.1)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (7893) - mean (119ms)  : 114, 123
    master - mean (117ms)  : 113, 121

    section Bailout
    This PR (7893) - mean (120ms)  : 116, 123
    master - mean (118ms)  : 114, 123

    section CallTarget+Inlining+NGEN
    This PR (7893) - mean (797ms)  : 728, 866
    master - mean (780ms)  : 725, 836

Loading
FakeDbCommand (.NET 6)
gantt
    title Execution time (ms) FakeDbCommand (.NET 6)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (7893) - mean (106ms)  : 103, 109
    master - mean (102ms)  : 98, 106

    section Bailout
    This PR (7893) - mean (106ms)  : 103, 109
    master - mean (103ms)  : 100, 105

    section CallTarget+Inlining+NGEN
    This PR (7893) - mean (762ms)  : 693, 831
    master - mean (741ms)  : 662, 820

Loading
FakeDbCommand (.NET 8)
gantt
    title Execution time (ms) FakeDbCommand (.NET 8)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (7893) - mean (104ms)  : 101, 107
    master - mean (100ms)  : 97, 103

    section Bailout
    This PR (7893) - mean (105ms)  : 102, 109
    master - mean (101ms)  : 100, 103

    section CallTarget+Inlining+NGEN
    This PR (7893) - mean (705ms)  : 686, 724
    master - mean (689ms)  : 670, 708

Loading
HttpMessageHandler (.NET Framework 4.8)
gantt
    title Execution time (ms) HttpMessageHandler (.NET Framework 4.8)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (7893) - mean (199ms)  : 193, 206
    master - mean (198ms)  : 193, 204

    section Bailout
    This PR (7893) - mean (203ms)  : 199, 207
    master - mean (201ms)  : 198, 205

    section CallTarget+Inlining+NGEN
    This PR (7893) - mean (1,165ms)  : 1118, 1212
    master - mean (1,165ms)  : 1110, 1219

Loading
HttpMessageHandler (.NET Core 3.1)
gantt
    title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (7893) - mean (285ms)  : 276, 295
    master - mean (283ms)  : 278, 289

    section Bailout
    This PR (7893) - mean (286ms)  : 280, 292
    master - mean (284ms)  : 278, 289

    section CallTarget+Inlining+NGEN
    This PR (7893) - mean (952ms)  : 897, 1008
    master - mean (966ms)  : 917, 1016

Loading
HttpMessageHandler (.NET 6)
gantt
    title Execution time (ms) HttpMessageHandler (.NET 6)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (7893) - mean (278ms)  : 270, 286
    master - mean (276ms)  : 269, 282

    section Bailout
    This PR (7893) - mean (278ms)  : 272, 283
    master - mean (277ms)  : 272, 282

    section CallTarget+Inlining+NGEN
    This PR (7893) - mean (958ms)  : 907, 1008
    master - mean (949ms)  : 887, 1011

Loading
HttpMessageHandler (.NET 8)
gantt
    title Execution time (ms) HttpMessageHandler (.NET 8)
    dateFormat  x
    axisFormat %Q
    todayMarker off
    section Baseline
    This PR (7893) - mean (277ms)  : 269, 285
    master - mean (278ms)  : 269, 286

    section Bailout
    This PR (7893) - mean (277ms)  : 272, 282
    master - mean (277ms)  : 272, 282

    section CallTarget+Inlining+NGEN
    This PR (7893) - mean (865ms)  : 829, 901
    master - mean (860ms)  : 825, 896

Loading

daniel-romano-DD and others added 6 commits January 5, 2026 10:16
## Summary of changes
Replaced custom mutex guard with `std::lock_guard`, using
`std::recursive_mutex` instead of `CRITICAL_SECTION` in windows and
`std::mutex` with railings in Linux

## Reason for change
Some locks have been spotted in smoke test wich could be cause by the
lack of thread recursive lock in the `std::mutex`

## Implementation details

## Test coverage

## Other details
<!-- Fixes #{issue} -->


<!--  ⚠️ Note:

Where possible, please obtain 2 approvals prior to merging. Unless
CODEOWNERS specifies otherwise, for external teams it is typically best
to have one review from a team member, and one review from apm-dotnet.
Trivial changes do not require 2 reviews.

MergeQueue is NOT enabled in this repository. If you have write access
to the repo, the PR has 1-2 approvals (see above), and all of the
required checks have passed, you can use the Squash and Merge button to
merge the PR. If you don't have write access, or you need help, reach
out in the #apm-dotnet channel in Slack.
-->
@vandonr vandonr requested review from a team as code owners January 5, 2026 12:34
@pr-commenter
Copy link

pr-commenter bot commented Jan 5, 2026

Benchmarks

Benchmark execution time: 2026-02-03 13:02:27

Comparing candidate commit 7527eb7 in PR branch vandonr/process3 with baseline commit 7c6440c in branch master.

Found 10 performance improvements and 11 performance regressions! Performance is the same for 156 metrics, 15 unstable metrics.

scenario:Benchmarks.Trace.AgentWriterBenchmark.WriteAndFlushEnrichedTraces net6.0

  • 🟩 execution_time [-81.263ms; -80.589ms] or [-39.877%; -39.546%]

scenario:Benchmarks.Trace.Asm.AppSecBodyBenchmark.ObjectExtractorSimpleBody net6.0

  • 🟩 execution_time [-23.277ms; -19.150ms] or [-10.486%; -8.627%]

scenario:Benchmarks.Trace.Asm.AppSecEncoderBenchmark.EncodeLegacyArgs net6.0

  • 🟩 execution_time [-27.643ms; -27.494ms] or [-13.527%; -13.454%]

scenario:Benchmarks.Trace.Asm.AppSecWafBenchmark.RunWafRealisticBenchmarkWithAttack net6.0

  • 🟩 execution_time [-41.039µs; -20.307µs] or [-12.302%; -6.087%]
  • 🟩 throughput [+212.318op/s; +397.097op/s] or [+7.071%; +13.226%]

scenario:Benchmarks.Trace.AspNetCoreBenchmark.SendRequest net6.0

  • 🟥 execution_time [+102.503ms; +103.198ms] or [+109.687%; +110.430%]

scenario:Benchmarks.Trace.AspNetCoreBenchmark.SendRequest netcoreapp3.1

  • 🟩 throughput [+641.814op/s; +1432.335op/s] or [+6.848%; +15.283%]

scenario:Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark.WriteAndFlushEnrichedTraces netcoreapp3.1

  • 🟥 execution_time [+18.357ms; +22.978ms] or [+9.817%; +12.288%]

scenario:Benchmarks.Trace.CharSliceBenchmark.OptimizedCharSlice net472

  • 🟥 execution_time [+99.926µs; +106.527µs] or [+5.192%; +5.535%]

scenario:Benchmarks.Trace.CharSliceBenchmark.OptimizedCharSlice net6.0

  • 🟥 execution_time [+85.449µs; +92.405µs] or [+6.227%; +6.734%]
  • 🟥 throughput [-46.175op/s; -42.557op/s] or [-6.336%; -5.840%]

scenario:Benchmarks.Trace.CharSliceBenchmark.OptimizedCharSliceWithPool netcoreapp3.1

  • 🟥 execution_time [+220.091µs; +229.736µs] or [+11.578%; +12.085%]
  • 🟥 throughput [-56.801op/s; -54.498op/s] or [-10.798%; -10.360%]

scenario:Benchmarks.Trace.ElasticsearchBenchmark.CallElasticsearchAsync netcoreapp3.1

  • 🟩 execution_time [-16.858ms; -12.604ms] or [-8.178%; -6.114%]

scenario:Benchmarks.Trace.SerilogBenchmark.EnrichedLog netcoreapp3.1

  • 🟥 throughput [-14902.467op/s; -12824.275op/s] or [-8.301%; -7.143%]

scenario:Benchmarks.Trace.SingleSpanAspNetCoreBenchmark.SingleSpanAspNetCore net6.0

  • 🟩 execution_time [-48.391ms; -34.307ms] or [-34.056%; -24.145%]

scenario:Benchmarks.Trace.SingleSpanAspNetCoreBenchmark.SingleSpanAspNetCore netcoreapp3.1

  • 🟥 throughput [-17556382.207op/s; -16052290.037op/s] or [-7.274%; -6.651%]

scenario:Benchmarks.Trace.SpanBenchmark.StartFinishScope netcoreapp3.1

  • 🟩 execution_time [-14.527ms; -11.010ms] or [-6.918%; -5.243%]

scenario:Benchmarks.Trace.SpanBenchmark.StartFinishTwoScopes net6.0

  • 🟥 execution_time [+18.197ms; +22.259ms] or [+9.153%; +11.195%]

scenario:Benchmarks.Trace.SpanBenchmark.StartFinishTwoScopes netcoreapp3.1

  • 🟩 execution_time [-18.269ms; -13.021ms] or [-8.536%; -6.084%]

scenario:Benchmarks.Trace.TraceAnnotationsBenchmark.RunOnMethodBegin net6.0

  • 🟥 execution_time [+14.111ms; +15.092ms] or [+7.022%; +7.510%]

Comment on lines 381 to 417
AgentHttpHeaderNames.MinimalHeaders,
BuildHeaders(containerId),
() => new MinimalAgentHeaderHelper(),
Copy link
Member

Choose a reason for hiding this comment

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

If you change one of these, you need to change both of them. Different ones are use for different transports. Which means you likely need a custom MinimalAgentHeaderHelper() here, something like this:

containerId is null
  ? () => new MinimalAgentHeaderHelper()
  : () => new MinimalWithContainerIdHelper()

I know, it sucks 😅

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hmm, yeah, not great, I have to do a different type because we use the instance to access a static field :/
btw, do you know why we don't use a normal Lazy in that helper ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I really didn't like the idea of duplicating the whole class, so i went another route, and made MinimalAgentHeaderHelper return a different value depending on whether it was given a container ID in the ctor.

/// </summary>
internal static KeyValuePair<string, string>[] BuildHeaders(string? containerId)
{
if (containerId != null)
Copy link
Member

Choose a reason for hiding this comment

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

We never "discover" this later, right? i.e. if containerId is non null the first time this is called, it will be non-null for ever more (and never change) right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes correct. Are you asking because if yes, then you'd have this code written differently, or just out of curiosity ?

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, if the answer had been "yes" we would have to write this differently, because we're building this collection once and never re-evaluating. Which is fine if this always gives the same result, but not otherwise 🙂

Copy link
Member

@andrewlock andrewlock left a comment

Choose a reason for hiding this comment

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

LGTM thanks 👍

private async Task ProcessDiscoveryResponse(IApiResponse response)
{
// Extract and store container tags hash from response headers
var containerTagsHash = response.GetHeader(AgentHttpHeaderNames.ContainerTagsHash);
Copy link
Member

Choose a reason for hiding this comment

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

I was wondering about this code, as we're going to do the work to extract and set this hash with every response, but I think that's fine, given that we shouldn't call the discovery service so much any more since #7979 (and also given the amount of work we do later in this method)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah, since it's not supposed to change, we could check if we already have it, and only query it then. But if you say it's fine :)

_metadataHeaders = string.Concat(headers);
}

if (_containerId != null)
Copy link
Member

Choose a reason for hiding this comment

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

I think we should probably refactor the MinimalAgentHeaderHelper code in general, there's some perf opportunities, and it feels like this is overall more complex than it needs to be, but I'll do that in a subsequent PR after you merge this 🙂

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok thanks. Yeah that code felt a bit... dated

// This product includes software developed at Datadog (https://www.datadoghq.com/). Copyright 2017 Datadog, Inc.
// </copyright>

#nullable enable
Copy link
Member

Choose a reason for hiding this comment

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

🙏

private const int MaxRetryDelayMs = 50;
private const int RecheckIntervalMs = 300_000;

private static readonly ContainerMetadata NullContainerMetadata = new(containerId: null, entityId: null);
Copy link
Member

Choose a reason for hiding this comment

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

nit: should prob do this in the TraceExporterTests too

Copy link
Contributor Author

@vandonr vandonr Feb 3, 2026

Choose a reason for hiding this comment

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

I did it here because it's used in many tests, but it's only used once in TraceExporterTests, so it feels less relevant to extract a property ?


var containerMetadata = NullContainerMetadata;

var ds = new DiscoveryService(factory, containerMetadata, InitialRetryDelayMs, MaxRetryDelayMs, RecheckIntervalMs);
Copy link
Member

Choose a reason for hiding this comment

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

RecheckIntervalMs = 300s - are you sure that's correct 🤔 If you "mis" the first check (which happens only 50ms (InitialRetryDelayMs) after calling new()), then this test will flake I think. It's rare, but looks like a definite possibility. If you set RecheckIntervalMs such that it is much smaller than the timeout you use in the mutex, then that should reduce the chance of flake I think?

EDIT: actually, this should be fine 😄 There's no real race condition here: the hash can be updated before subcribetochanges is called, but the mutex is guaranteed to be called in that case. Ignore me 😄

vandonr and others added 3 commits February 3, 2026 13:16
Co-authored-by: Andrew Lock <andrew.lock@datadoghq.com>
Co-authored-by: Andrew Lock <andrew.lock@datadoghq.com>
Co-authored-by: Andrew Lock <andrew.lock@datadoghq.com>
@vandonr vandonr merged commit 5cbcfa8 into master Feb 3, 2026
144 of 145 checks passed
@vandonr vandonr deleted the vandonr/process3 branch February 3, 2026 18:49
@github-actions github-actions bot added this to the vNext-v3 milestone Feb 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants