Make more integration settings case insensitive #6393

andrewlock · 2024-12-03T16:03:18Z

Summary of changes

Make the other settings in IntegrationSettings case-insensitive for the IntegrationId

Reason for change

In #6175 we made the DD_TRACE_{0}_ENABLED configurations case-insensitive for the IntegrationId. This PR it makes the other related settings behave similarly

Implementation details

Add additional fallbacks, the same as for the Enabled case

Test coverage

Added unit test for it

Other details

Switched the string.Format to interpolated because, you know, it's 2024

link04

LGTM

datadog-ddstaging · 2024-12-03T16:27:15Z

Datadog Report

Branch report: andrew/fix-integration-settings
Commit report: 8bb66dd
Test service: dd-trace-dotnet

✅ 0 Failed, 450133 Passed, 2763 Skipped, 20h 17m 23.8s Total Time
❄️ 2 New Flaky

New Flaky Tests (2)

FlakyRetries - Datadog.Trace.ClrProfiler.IntegrationTests.CI.MsTestV2RetriesTests - Last Failure
Expand for error
```
 The sample did not exit in 600000ms. Memory dump taken: True. Killing process.
```
FlakyRetries - Datadog.Trace.ClrProfiler.IntegrationTests.CI.NUnitRetriesTests - Last Failure
Expand for error
```
 The sample did not exit in 600000ms. Memory dump taken: True. Killing process.
```

andrewlock · 2024-12-03T17:21:12Z

Execution-Time Benchmarks Report ⏱️

Execution-time results for samples comparing the following branches/commits:

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 shown 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).

gantt
    title Execution time (ms) FakeDbCommand (.NET Framework 4.6.2) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Baseline
    This PR (6393) - mean (69ms)  : 66, 72
     .   : milestone, 69,
    master - mean (69ms)  : 66, 72
     .   : milestone, 69,

    section CallTarget+Inlining+NGEN
    This PR (6393) - mean (981ms)  : 954, 1008
     .   : milestone, 981,
    master - mean (977ms)  : 957, 996
     .   : milestone, 977,

gantt
    title Execution time (ms) FakeDbCommand (.NET Core 3.1) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Baseline
    This PR (6393) - mean (108ms)  : 105, 111
     .   : milestone, 108,
    master - mean (108ms)  : 106, 110
     .   : milestone, 108,

    section CallTarget+Inlining+NGEN
    This PR (6393) - mean (680ms)  : 664, 696
     .   : milestone, 680,
    master - mean (677ms)  : 661, 692
     .   : milestone, 677,

gantt
    title Execution time (ms) FakeDbCommand (.NET 6) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Baseline
    This PR (6393) - mean (92ms)  : 89, 94
     .   : milestone, 92,
    master - mean (91ms)  : 89, 94
     .   : milestone, 91,

    section CallTarget+Inlining+NGEN
    This PR (6393) - mean (634ms)  : 618, 650
     .   : milestone, 634,
    master - mean (634ms)  : 616, 652
     .   : milestone, 634,

gantt
    title Execution time (ms) HttpMessageHandler (.NET Framework 4.6.2) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Baseline
    This PR (6393) - mean (190ms)  : 187, 194
     .   : milestone, 190,
    master - mean (190ms)  : 186, 195
     .   : milestone, 190,

    section CallTarget+Inlining+NGEN
    This PR (6393) - mean (1,094ms)  : 1057, 1131
     .   : milestone, 1094,
    master - mean (1,090ms)  : 1059, 1121
     .   : milestone, 1090,

gantt
    title Execution time (ms) HttpMessageHandler (.NET Core 3.1) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Baseline
    This PR (6393) - mean (277ms)  : 273, 281
     .   : milestone, 277,
    master - mean (277ms)  : 273, 281
     .   : milestone, 277,

    section CallTarget+Inlining+NGEN
    This PR (6393) - mean (874ms)  : 838, 909
     .   : milestone, 874,
    master - mean (870ms)  : 839, 901
     .   : milestone, 870,

gantt
    title Execution time (ms) HttpMessageHandler (.NET 6) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Baseline
    This PR (6393) - mean (266ms)  : 261, 271
     .   : milestone, 266,
    master - mean (266ms)  : 260, 271
     .   : milestone, 266,

    section CallTarget+Inlining+NGEN
    This PR (6393) - mean (850ms)  : 813, 887
     .   : milestone, 850,
    master - mean (849ms)  : 812, 887
     .   : milestone, 849,

andrewlock · 2024-12-03T20:36:28Z

Benchmarks Report for tracer 🐌

Benchmarks for #6393 compared to master:

2 benchmarks are slower, with geometric mean 1.169
All benchmarks have the same allocations

The following thresholds were used for comparing the benchmark speeds:

Mann–Whitney U test with statistical test for significance of 5%
Only results indicating a difference greater than 10% and 0.3 ns are considered.

Allocation changes below 0.5% are ignored.

Benchmark details

Benchmarks.Trace.ActivityBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Gen 1	Gen 2	Allocated
master	`StartStopWithChild`	net6.0	7.76μs	43.4ns	294ns	0.0165	0.00826	0	5.62 KB
master	`StartStopWithChild`	netcoreapp3.1	10μs	55.2ns	336ns	0.0188	0.0094	0	5.8 KB
master	`StartStopWithChild`	net472	16.1μs	39.6ns	153ns	1.05	0.32	0.0959	6.21 KB
#6393	`StartStopWithChild`	net6.0	7.99μs	45.3ns	320ns	0.0163	0.00815	0	5.61 KB
#6393	`StartStopWithChild`	netcoreapp3.1	10μs	54.6ns	423ns	0.0201	0.01	0	5.8 KB
#6393	`StartStopWithChild`	net472	16μs	62.3ns	241ns	1.06	0.322	0.105	6.2 KB

Benchmarks.Trace.AgentWriterBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`WriteAndFlushEnrichedTraces`	net6.0	500μs	1.58μs	6.11μs	0	2.7 KB
master	`WriteAndFlushEnrichedTraces`	netcoreapp3.1	637μs	199ns	771ns	0	2.7 KB
master	`WriteAndFlushEnrichedTraces`	net472	841μs	636ns	2.46μs	0.419	3.3 KB
#6393	`WriteAndFlushEnrichedTraces`	net6.0	485μs	324ns	1.21μs	0	2.7 KB
#6393	`WriteAndFlushEnrichedTraces`	netcoreapp3.1	642μs	392ns	1.52μs	0	2.7 KB
#6393	`WriteAndFlushEnrichedTraces`	net472	838μs	475ns	1.78μs	0.419	3.3 KB

Benchmarks.Trace.AspNetCoreBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`SendRequest`	net6.0	147μs	861ns	7.7μs	0.156	14.47 KB
master	`SendRequest`	netcoreapp3.1	163μs	923ns	6.26μs	0.163	17.27 KB
master	`SendRequest`	net472	0.000374ns	0.00021ns	0.000759ns	0	0 b
#6393	`SendRequest`	net6.0	148μs	771ns	3.7μs	0.141	14.47 KB
#6393	`SendRequest`	netcoreapp3.1	166μs	963ns	8.23μs	0.162	17.27 KB
#6393	`SendRequest`	net472	0.00037ns	0.000297ns	0.00107ns	0	0 b

Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Gen 1	Gen 2	Allocated
master	`WriteAndFlushEnrichedTraces`	net6.0	560μs	2.91μs	15.1μs	0.579	0	0	41.67 KB
master	`WriteAndFlushEnrichedTraces`	netcoreapp3.1	679μs	2.14μs	8.29μs	0.338	0	0	41.7 KB
master	`WriteAndFlushEnrichedTraces`	net472	882μs	4.02μs	15.6μs	8.25	2.6	0.434	53.32 KB
#6393	`WriteAndFlushEnrichedTraces`	net6.0	572μs	1.67μs	6.23μs	0.571	0	0	41.62 KB
#6393	`WriteAndFlushEnrichedTraces`	netcoreapp3.1	683μs	3.34μs	14.9μs	0.34	0	0	41.72 KB
#6393	`WriteAndFlushEnrichedTraces`	net472	864μs	3.88μs	15μs	8.19	2.59	0.431	53.28 KB

Benchmarks.Trace.DbCommandBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Gen 1	Allocated
master	`ExecuteNonQuery`	net6.0	1.29μs	0.622ns	2.41ns	0.0141	0	1.02 KB
master	`ExecuteNonQuery`	netcoreapp3.1	1.78μs	1.85ns	7.16ns	0.0142	0	1.02 KB
master	`ExecuteNonQuery`	net472	2.11μs	1.75ns	6.54ns	0.156	0.00105	987 B
#6393	`ExecuteNonQuery`	net6.0	1.31μs	0.97ns	3.76ns	0.0145	0	1.02 KB
#6393	`ExecuteNonQuery`	netcoreapp3.1	1.81μs	2.73ns	10.6ns	0.0135	0	1.02 KB
#6393	`ExecuteNonQuery`	net472	2.05μs	0.962ns	3.6ns	0.156	0.00103	987 B

Benchmarks.Trace.ElasticsearchBenchmark - Slower ⚠️ Same allocations ✔️

Slower ⚠️ in #6393

Benchmark	diff/base	Base Median (ns)	Diff Median (ns)	Modality
Benchmarks.Trace.ElasticsearchBenchmark.CallElasticsearch‑net6.0	1.186	1,096.31	1,299.70

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`CallElasticsearch`	net6.0	1.1μs	0.635ns	2.38ns	0.0137	976 B
master	`CallElasticsearch`	netcoreapp3.1	1.62μs	0.584ns	2.02ns	0.013	976 B
master	`CallElasticsearch`	net472	2.62μs	1.98ns	7.66ns	0.158	995 B
master	`CallElasticsearchAsync`	net6.0	1.21μs	0.559ns	2.16ns	0.0133	952 B
master	`CallElasticsearchAsync`	netcoreapp3.1	1.64μs	1.27ns	4.56ns	0.0139	1.02 KB
master	`CallElasticsearchAsync`	net472	2.59μs	0.914ns	3.3ns	0.167	1.05 KB
#6393	`CallElasticsearch`	net6.0	1.3μs	0.615ns	2.3ns	0.0136	976 B
#6393	`CallElasticsearch`	netcoreapp3.1	1.62μs	7.43ns	28.8ns	0.0132	976 B
#6393	`CallElasticsearch`	net472	2.5μs	1.13ns	4.24ns	0.157	995 B
#6393	`CallElasticsearchAsync`	net6.0	1.34μs	1.68ns	6.28ns	0.013	952 B
#6393	`CallElasticsearchAsync`	netcoreapp3.1	1.64μs	0.96ns	3.59ns	0.0139	1.02 KB
#6393	`CallElasticsearchAsync`	net472	2.62μs	0.715ns	2.68ns	0.167	1.05 KB

Benchmarks.Trace.GraphQLBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`ExecuteAsync`	net6.0	1.31μs	1.13ns	4.36ns	0.0137	952 B
master	`ExecuteAsync`	netcoreapp3.1	1.65μs	0.829ns	2.99ns	0.0123	952 B
master	`ExecuteAsync`	net472	1.8μs	0.627ns	2.43ns	0.145	915 B
#6393	`ExecuteAsync`	net6.0	1.21μs	1.12ns	4.19ns	0.0133	952 B
#6393	`ExecuteAsync`	netcoreapp3.1	1.68μs	0.622ns	2.33ns	0.0127	952 B
#6393	`ExecuteAsync`	net472	1.79μs	0.697ns	2.61ns	0.145	915 B

Benchmarks.Trace.HttpClientBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`SendAsync`	net6.0	4.52μs	10.4ns	40.1ns	0.0314	2.31 KB
master	`SendAsync`	netcoreapp3.1	5.34μs	1.79ns	6.46ns	0.0373	2.85 KB
master	`SendAsync`	net472	7.35μs	2.71ns	10.5ns	0.494	3.12 KB
#6393	`SendAsync`	net6.0	4.39μs	1.33ns	4.97ns	0.0305	2.31 KB
#6393	`SendAsync`	netcoreapp3.1	5.36μs	1.65ns	6.4ns	0.0378	2.85 KB
#6393	`SendAsync`	net472	7.39μs	1.98ns	7.43ns	0.495	3.12 KB

Benchmarks.Trace.ILoggerBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`EnrichedLog`	net6.0	1.51μs	3.83ns	14.8ns	0.0227	1.64 KB
master	`EnrichedLog`	netcoreapp3.1	2.25μs	0.994ns	3.72ns	0.0226	1.64 KB
master	`EnrichedLog`	net472	2.61μs	0.894ns	3.35ns	0.249	1.57 KB
#6393	`EnrichedLog`	net6.0	1.61μs	1.14ns	4.41ns	0.0227	1.64 KB
#6393	`EnrichedLog`	netcoreapp3.1	2.15μs	1.36ns	4.92ns	0.0226	1.64 KB
#6393	`EnrichedLog`	net472	2.49μs	1.8ns	6.74ns	0.25	1.57 KB

Benchmarks.Trace.Log4netBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Gen 1	Allocated
master	`EnrichedLog`	net6.0	118μs	209ns	811ns	0.0595	0	4.28 KB
master	`EnrichedLog`	netcoreapp3.1	125μs	154ns	598ns	0	0	4.28 KB
master	`EnrichedLog`	net472	153μs	164ns	637ns	0.689	0.23	4.46 KB
#6393	`EnrichedLog`	net6.0	120μs	194ns	751ns	0.0608	0	4.28 KB
#6393	`EnrichedLog`	netcoreapp3.1	125μs	181ns	700ns	0	0	4.28 KB
#6393	`EnrichedLog`	net472	151μs	282ns	1.09μs	0.678	0.226	4.46 KB

Benchmarks.Trace.NLogBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`EnrichedLog`	net6.0	3.14μs	1.54ns	5.98ns	0.0309	2.2 KB
master	`EnrichedLog`	netcoreapp3.1	4.26μs	1.48ns	5.75ns	0.0296	2.2 KB
master	`EnrichedLog`	net472	4.78μs	2.13ns	8.23ns	0.319	2.02 KB
#6393	`EnrichedLog`	net6.0	3.04μs	0.91ns	3.52ns	0.0301	2.2 KB
#6393	`EnrichedLog`	netcoreapp3.1	4.19μs	1.55ns	5.58ns	0.0277	2.2 KB
#6393	`EnrichedLog`	net472	5.07μs	1.15ns	4.45ns	0.318	2.02 KB

Benchmarks.Trace.RedisBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`SendReceive`	net6.0	1.32μs	1.64ns	6.12ns	0.0162	1.14 KB
master	`SendReceive`	netcoreapp3.1	1.81μs	0.814ns	3.15ns	0.0154	1.14 KB
master	`SendReceive`	net472	2.06μs	1.1ns	3.96ns	0.183	1.16 KB
#6393	`SendReceive`	net6.0	1.4μs	0.738ns	2.76ns	0.016	1.14 KB
#6393	`SendReceive`	netcoreapp3.1	1.76μs	1.23ns	4.76ns	0.0151	1.14 KB
#6393	`SendReceive`	net472	2.06μs	1.97ns	7.37ns	0.183	1.16 KB

Benchmarks.Trace.SerilogBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`EnrichedLog`	net6.0	2.75μs	1.63ns	6.1ns	0.0221	1.6 KB
master	`EnrichedLog`	netcoreapp3.1	3.98μs	1.86ns	7.22ns	0.0217	1.65 KB
master	`EnrichedLog`	net472	4.45μs	2.51ns	9.74ns	0.323	2.04 KB
#6393	`EnrichedLog`	net6.0	2.84μs	0.884ns	3.42ns	0.0228	1.6 KB
#6393	`EnrichedLog`	netcoreapp3.1	3.85μs	3.9ns	15.1ns	0.021	1.65 KB
#6393	`EnrichedLog`	net472	4.49μs	2.22ns	8.3ns	0.322	2.04 KB

Benchmarks.Trace.SpanBenchmark - Slower ⚠️ Same allocations ✔️

Slower ⚠️ in #6393

Benchmark	diff/base	Base Median (ns)	Diff Median (ns)	Modality
Benchmarks.Trace.SpanBenchmark.StartFinishScope‑net472	1.154	819.52	945.35

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`StartFinishSpan`	net6.0	421ns	0.693ns	2.68ns	0.00816	576 B
master	`StartFinishSpan`	netcoreapp3.1	643ns	1.54ns	5.95ns	0.00777	576 B
master	`StartFinishSpan`	net472	669ns	1.34ns	5.21ns	0.0915	578 B
master	`StartFinishScope`	net6.0	488ns	0.756ns	2.93ns	0.00976	696 B
master	`StartFinishScope`	netcoreapp3.1	737ns	0.902ns	3.37ns	0.00955	696 B
master	`StartFinishScope`	net472	819ns	1.43ns	5.55ns	0.105	658 B
#6393	`StartFinishSpan`	net6.0	395ns	0.613ns	2.37ns	0.00806	576 B
#6393	`StartFinishSpan`	netcoreapp3.1	631ns	0.784ns	3.04ns	0.00788	576 B
#6393	`StartFinishSpan`	net472	634ns	1.46ns	5.67ns	0.0916	578 B
#6393	`StartFinishScope`	net6.0	534ns	0.876ns	3.39ns	0.00971	696 B
#6393	`StartFinishScope`	netcoreapp3.1	695ns	1.37ns	5.29ns	0.00946	696 B
#6393	`StartFinishScope`	net472	942ns	2.85ns	11.1ns	0.104	658 B

Benchmarks.Trace.TraceAnnotationsBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`RunOnMethodBegin`	net6.0	661ns	0.835ns	3.24ns	0.00965	696 B
master	`RunOnMethodBegin`	netcoreapp3.1	897ns	1.03ns	3.86ns	0.00938	696 B
master	`RunOnMethodBegin`	net472	1.2μs	2.45ns	9.5ns	0.104	658 B
#6393	`RunOnMethodBegin`	net6.0	658ns	1.11ns	4.31ns	0.00989	696 B
#6393	`RunOnMethodBegin`	netcoreapp3.1	971ns	1.84ns	7.13ns	0.00928	696 B
#6393	`RunOnMethodBegin`	net472	1.16μs	1.91ns	7.41ns	0.104	658 B

andrewlock · 2024-12-04T15:42:06Z

Throughput/Crank Report ⚡

Throughput results for AspNetCoreSimpleController comparing the following branches/commits:

Cases where throughput results for the PR are worse than latest master (5% drop or greater), results are shown in red.

Note that these results are based on a single point-in-time result for each branch. For full results, see one of the many, many dashboards!

gantt
    title Throughput Linux x64 (Total requests) 
    dateFormat  X
    axisFormat %s
    section Baseline
    This PR (6393) (11.214M)   : 0, 11214213
    master (11.163M)   : 0, 11163279
    benchmarks/2.9.0 (11.033M)   : 0, 11032866

    section Automatic
    This PR (6393) (7.263M)   : 0, 7263142
    master (7.379M)   : 0, 7378518
    benchmarks/2.9.0 (7.786M)   : 0, 7785853

    section Trace stats
    master (7.698M)   : 0, 7697685

    section Manual
    master (11.208M)   : 0, 11207970

    section Manual + Automatic
    This PR (6393) (6.849M)   : 0, 6848954
    master (6.848M)   : 0, 6847878

    section DD_TRACE_ENABLED=0
    master (10.300M)   : 0, 10300258

gantt
    title Throughput Linux arm64 (Total requests) 
    dateFormat  X
    axisFormat %s
    section Baseline
    This PR (6393) (9.680M)   : 0, 9679570
    master (9.614M)   : 0, 9613662
    benchmarks/2.9.0 (9.495M)   : 0, 9494821

    section Automatic
    This PR (6393) (6.390M)   : 0, 6389886
    master (6.420M)   : 0, 6420484

    section Trace stats
    master (6.620M)   : 0, 6620303

    section Manual
    master (9.598M)   : 0, 9598372

    section Manual + Automatic
    This PR (6393) (5.938M)   : 0, 5938135
    master (5.968M)   : 0, 5968390

    section DD_TRACE_ENABLED=0
    master (8.911M)   : 0, 8911128

gantt
    title Throughput Windows x64 (Total requests) 
    dateFormat  X
    axisFormat %s
    section Baseline
    This PR (6393) (10.519M)   : 0, 10518733
    master (9.949M)   : 0, 9949075
    benchmarks/2.9.0 (10.020M)   : 0, 10019592

    section Automatic
    This PR (6393) (6.617M)   : 0, 6617289
    master (6.538M)   : 0, 6537814
    benchmarks/2.9.0 (7.255M)   : 0, 7255257

    section Trace stats
    master (7.075M)   : 0, 7075474

    section Manual
    master (9.758M)   : 0, 9757921

    section Manual + Automatic
    This PR (6393) (6.274M)   : 0, 6273953
    master (6.151M)   : 0, 6151047

    section DD_TRACE_ENABLED=0
    master (9.404M)   : 0, 9403695

…nSource` (#6397) Change how we "apply" settings from manual configuration to the automatic side to use `IConfigurationSource` ## Reason for change The previous design of how we "apply" settings made in code using manual instrumentation required mutating a `TracerSettings` object after it was already built. In fact, this is pretty much the _only_ place that we mutate the settings. By switching to using a "configuration source" approach, so that the settings are built _once_ with the correct values opens up the option to make these immutable (and therefore delete all of the `Immutable*` settings we currently have. This reduces both code duplication and work we do on startup, and opens the path to further refactoring improvements. Note that the public API does not change, so consumers of Datadog.Trace.Manual are still working with a mutable object initially. ## Implementation details Currently we pass a `Dictionary<string, object>` between the manual and automatic side. Previously, we then iterated the keys, compared against known values, and modified `TracerSettings` as required. With the changes, we have a `ManualInstrumentationConfigurationSource` which just "wraps" the `Dictionary<>`, and returns the correct value as required for a given key. Overall, I think this is much cleaner. Where things get messy is how we handle disabling specific integrations. The existing dictionary is optimised for looping through the provided values, fetching the setting that needs to be modified, and changing all the required properties. Unfortunately, the `IConfigurationSource` approach where we're looking up by a key like `DD_TRACE_NPGSQL_ENABLED` works _horribly_ for this pattern 🙁. So I introduced an additional approach which explicitly _additionally_ transfers the settings using these values, making them just "standard" lookups. > Note that due to backwards + forwards compatibility requirements > - We _still_ need to send the "old" version of integration settings from the manual side, in case it's used with an old version of the auto instrumentation > - We _still_ need to handle the "old" version of integration settings in the auto side, in case it's used with an old version of the manual instrumentation. > - At least in this case we can use the more efficient `IConfigurationSource` reader, so we don't pay the expense of retrieving the settings. The only downside is a couple of extra allocations when they _do_ disable integrations in code. Minor other changes: - Add helper ctor to `CompositeConfigurationSource` for creating the internal list from a collection of `IConfigurationSource` - Tweak `DictionaryObjectConfigurationSource` so we can derive from it - Create a separate integration for <3.7.0 manual instrumentation that uses the legacy settings, otherwise use the new settings objects ## Test coverage Mostly covered by existing unit tests (and indirectly by integration tests). Tweaked the test to test both the new and legacy configuration source. ## Other details Requires #6393 to fix how we read integration settings Part of stack - #6370 - #6376 - #6385 - #6386 - #6397 👈 This PR - #6399 - #6400 - #6405 - #6408

## Summary of changes Make the other settings in `IntegrationSettings` case-insensitive for the `IntegrationId` ## Reason for change In #6175 we made the `DD_TRACE_{0}_ENABLED` configurations case-insensitive for the `IntegrationId`. This PR it makes the other related settings behave similarly ## Implementation details Add additional fallbacks, the same as for the Enabled case ## Test coverage Added unit test for it ## Other details Switched the string.Format to interpolated because, you know, it's 2024

…nSource` (#6397) Change how we "apply" settings from manual configuration to the automatic side to use `IConfigurationSource` ## Reason for change The previous design of how we "apply" settings made in code using manual instrumentation required mutating a `TracerSettings` object after it was already built. In fact, this is pretty much the _only_ place that we mutate the settings. By switching to using a "configuration source" approach, so that the settings are built _once_ with the correct values opens up the option to make these immutable (and therefore delete all of the `Immutable*` settings we currently have. This reduces both code duplication and work we do on startup, and opens the path to further refactoring improvements. Note that the public API does not change, so consumers of Datadog.Trace.Manual are still working with a mutable object initially. ## Implementation details Currently we pass a `Dictionary<string, object>` between the manual and automatic side. Previously, we then iterated the keys, compared against known values, and modified `TracerSettings` as required. With the changes, we have a `ManualInstrumentationConfigurationSource` which just "wraps" the `Dictionary<>`, and returns the correct value as required for a given key. Overall, I think this is much cleaner. Where things get messy is how we handle disabling specific integrations. The existing dictionary is optimised for looping through the provided values, fetching the setting that needs to be modified, and changing all the required properties. Unfortunately, the `IConfigurationSource` approach where we're looking up by a key like `DD_TRACE_NPGSQL_ENABLED` works _horribly_ for this pattern 🙁. So I introduced an additional approach which explicitly _additionally_ transfers the settings using these values, making them just "standard" lookups. > Note that due to backwards + forwards compatibility requirements > - We _still_ need to send the "old" version of integration settings from the manual side, in case it's used with an old version of the auto instrumentation > - We _still_ need to handle the "old" version of integration settings in the auto side, in case it's used with an old version of the manual instrumentation. > - At least in this case we can use the more efficient `IConfigurationSource` reader, so we don't pay the expense of retrieving the settings. The only downside is a couple of extra allocations when they _do_ disable integrations in code. Minor other changes: - Add helper ctor to `CompositeConfigurationSource` for creating the internal list from a collection of `IConfigurationSource` - Tweak `DictionaryObjectConfigurationSource` so we can derive from it - Create a separate integration for <3.7.0 manual instrumentation that uses the legacy settings, otherwise use the new settings objects ## Test coverage Mostly covered by existing unit tests (and indirectly by integration tests). Tweaked the test to test both the new and legacy configuration source. ## Other details Requires #6393 to fix how we read integration settings Part of stack - #6370 - #6376 - #6385 - #6386 - #6397 👈 This PR - #6399 - #6400 - #6405 - #6408

Make more integration settings case insensitive

0f1688b

andrewlock added the area:tracer The core tracer library (Datadog.Trace, does not include OpenTracing, native code, or integrations) label Dec 3, 2024

andrewlock requested a review from a team as a code owner December 3, 2024 16:03

link04 approved these changes Dec 3, 2024

View reviewed changes

Fixes

22b5522

andrewlock mentioned this pull request Dec 4, 2024

Update config-in-code manual instrumentation to use an IConfigurationSource #6397

Merged

Exclude interpolated string from tests

8bb66dd

andrewlock merged commit 1afb539 into master Dec 4, 2024
64 of 65 checks passed

andrewlock deleted the andrew/fix-integration-settings branch December 4, 2024 18:05

github-actions bot added this to the vNext-v3 milestone Dec 4, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make more integration settings case insensitive #6393

Make more integration settings case insensitive #6393

andrewlock commented Dec 3, 2024

link04 left a comment

datadog-ddstaging bot commented Dec 3, 2024 •

edited

Loading

andrewlock commented Dec 3, 2024 •

edited

Loading

andrewlock commented Dec 3, 2024 •

edited

Loading

Raw results

Raw results

Raw results

Raw results

Raw results

Slower ⚠️ in #6393

Raw results

Raw results

Raw results

Raw results

Raw results

Raw results

Raw results

Raw results

Slower ⚠️ in #6393

Raw results

Raw results

andrewlock commented Dec 4, 2024

Make more integration settings case insensitive #6393

Make more integration settings case insensitive #6393

Conversation

andrewlock commented Dec 3, 2024

Summary of changes

Reason for change

Implementation details

Test coverage

Other details

link04 left a comment

Choose a reason for hiding this comment

datadog-ddstaging bot commented Dec 3, 2024 • edited Loading

Datadog Report

New Flaky Tests (2)

andrewlock commented Dec 3, 2024 • edited Loading

Execution-Time Benchmarks Report ⏱️

andrewlock commented Dec 3, 2024 • edited Loading

Benchmarks Report for tracer 🐌

Benchmark details

Raw results

Raw results

Raw results

Raw results

Raw results

Slower ⚠️ in #6393

Raw results

Raw results

Raw results

Raw results

Raw results

Raw results

Raw results

Raw results

Slower ⚠️ in #6393

Raw results

Raw results

andrewlock commented Dec 4, 2024

Throughput/Crank Report ⚡

datadog-ddstaging bot commented Dec 3, 2024 •

edited

Loading

andrewlock commented Dec 3, 2024 •

edited

Loading

andrewlock commented Dec 3, 2024 •

edited

Loading