Simplify duplication in `IConfigurationSource` #6386

andrewlock · 2024-12-03T12:01:31Z

Summary of changes

Delete legacy IConfigurationSource
Rename ITelmeteredConfigurationSource => IConfigurationSource
Remove some "public" API workarounds
Make some APIs public instead of internal (just to satisfy compiler)
Fix tests

Reason for change

ITelmeteredConfigurationSource was introduced when IConfigurationSource was public, and so could not be changed. We have since removed that interface from the public API (it's not in Datadog.trace.Manual) so now it simply adds confusion and complexity (as it should not be used internally in Datadog.Trace).

Implementation details

This PR looks more complex than it is, because in order to replace all the usages of the old IConfigurationSource with the new one, I had to mark some other APIs public (and document them to satisfy the analyzers).

It is mostly

Delete legacy IConfigurationSource
Rename ITelmeteredConfigurationSource => IConfigurationSource
Fix any errors

I took the opportunity to also remove some of the *Internal methods which were used to avoid calling the "public" APIs; seeing as these aren't actually public any more, that's just unnecessary duplication.

Test coverage

The testing was a pain. The ConfigurationBuilder tests were all designed to check that ITelmeteredConfigurationSource gave the same results as IConfigurationSource (while never explicitly specifying what the "expected" behaviour was. I took some time to enumerate the actual expected values for the NameValueCollection source, but the Json source has very different behaviour that is more of a pain to test, so I chose to simplify a lot there. We could do a lot to clean up those tests, but I didn't want to add even more complexity in this PR.

Other details

To help "fix" the ASM tests I introduced a DictionaryObjectConfigurationSource, in which you pass in a Dictionary<string, object>. This is useful for testing (as it was previously used) but is actually going to be useful for a future clean-up PR too, so I kept it in Datadog.Trace instead of in the test project.

Part of stack

datadog-ddstaging · 2024-12-03T12:30:58Z

Datadog Report

Branch report: andrew/simplify-configuration-sources
Commit report: 3b52a69
Test service: dd-trace-dotnet

✅ 0 Failed, 456178 Passed, 2772 Skipped, 18h 32m 19.47s Total Time

andrewlock · 2024-12-03T13:19:16Z

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 (6386) - mean (69ms)  : 67, 72
     .   : milestone, 69,
    master - mean (70ms)  : 64, 76
     .   : milestone, 70,

    section CallTarget+Inlining+NGEN
    This PR (6386) - mean (982ms)  : 958, 1005
     .   : milestone, 982,
    master - mean (983ms)  : 951, 1016
     .   : milestone, 983,

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

    section CallTarget+Inlining+NGEN
    This PR (6386) - mean (681ms)  : 665, 698
     .   : milestone, 681,
    master - mean (683ms)  : 668, 698
     .   : milestone, 683,

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

    section CallTarget+Inlining+NGEN
    This PR (6386) - mean (640ms)  : 620, 660
     .   : milestone, 640,
    master - mean (630ms)  : 611, 649
     .   : milestone, 630,

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

    section CallTarget+Inlining+NGEN
    This PR (6386) - mean (1,094ms)  : 1055, 1134
     .   : milestone, 1094,
    master - mean (1,093ms)  : 1061, 1124
     .   : milestone, 1093,

gantt
    title Execution time (ms) HttpMessageHandler (.NET Core 3.1) 
    dateFormat  X
    axisFormat %s
    todayMarker off
    section Baseline
    This PR (6386) - mean (275ms)  : 271, 280
     .   : milestone, 275,
    master - mean (276ms)  : 272, 280
     .   : milestone, 276,

    section CallTarget+Inlining+NGEN
    This PR (6386) - mean (869ms)  : 843, 896
     .   : milestone, 869,
    master - mean (872ms)  : 833, 911
     .   : milestone, 872,

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

    section CallTarget+Inlining+NGEN
    This PR (6386) - mean (849ms)  : 817, 881
     .   : milestone, 849,
    master - mean (850ms)  : 814, 886
     .   : milestone, 850,

andrewlock · 2024-12-03T14:41:29Z

Benchmarks Report for appsec 🐌

Benchmarks for #6386 compared to master:

All benchmarks have the same speed
1 benchmarks have fewer allocations
1 benchmarks have more 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.Asm.AppSecBodyBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Gen 1	Allocated
master	`AllCycleSimpleBody`	net6.0	197μs	117ns	436ns	2.85	0.0984	205.62 KB
master	`AllCycleSimpleBody`	netcoreapp3.1	302μs	111ns	400ns	2.88	0	213.06 KB
master	`AllCycleSimpleBody`	net472	266μs	276ns	1.03μs	38.1	2.83	240.26 KB
master	`AllCycleMoreComplexBody`	net6.0	226μs	98.9ns	370ns	2.93	0.113	209.13 KB
master	`AllCycleMoreComplexBody`	netcoreapp3.1	303μs	107ns	387ns	2.9	0	216.48 KB
master	`AllCycleMoreComplexBody`	net472	265μs	169ns	655ns	38.6	2.93	243.77 KB
master	`ObjectExtractorSimpleBody`	net6.0	142ns	0.143ns	0.554ns	0.00397	0	280 B
master	`ObjectExtractorSimpleBody`	netcoreapp3.1	195ns	0.181ns	0.676ns	0.00373	0	272 B
master	`ObjectExtractorSimpleBody`	net472	216ns	0.181ns	0.676ns	0.0446	0	281 B
master	`ObjectExtractorMoreComplexBody`	net6.0	2.9μs	1.08ns	4.18ns	0.0536	0	3.78 KB
master	`ObjectExtractorMoreComplexBody`	netcoreapp3.1	3.76μs	1.82ns	6.82ns	0.0508	0	3.69 KB
master	`ObjectExtractorMoreComplexBody`	net472	4.22μs	7.46ns	28.9ns	0.603	0.00639	3.8 KB
#6386	`AllCycleSimpleBody`	net6.0	215μs	126ns	471ns	2.89	0.107	205.48 KB
#6386	`AllCycleSimpleBody`	netcoreapp3.1	315μs	236ns	884ns	2.86	0	212.92 KB
#6386	`AllCycleSimpleBody`	net472	278μs	63.7ns	230ns	38	2.94	240.1 KB
#6386	`AllCycleMoreComplexBody`	net6.0	221μs	58.4ns	202ns	2.97	0.11	208.98 KB
#6386	`AllCycleMoreComplexBody`	netcoreapp3.1	319μs	255ns	955ns	2.88	0	216.34 KB
#6386	`AllCycleMoreComplexBody`	net472	289μs	598ns	2.32μs	38.6	2.86	243.61 KB
#6386	`ObjectExtractorSimpleBody`	net6.0	147ns	0.113ns	0.436ns	0.00395	0	280 B
#6386	`ObjectExtractorSimpleBody`	netcoreapp3.1	197ns	0.14ns	0.544ns	0.00377	0	272 B
#6386	`ObjectExtractorSimpleBody`	net472	233ns	0.478ns	1.79ns	0.0446	0	281 B
#6386	`ObjectExtractorMoreComplexBody`	net6.0	2.95μs	1.58ns	5.92ns	0.053	0	3.78 KB
#6386	`ObjectExtractorMoreComplexBody`	netcoreapp3.1	3.8μs	2.9ns	11.2ns	0.0514	0	3.69 KB
#6386	`ObjectExtractorMoreComplexBody`	net472	4.27μs	4.37ns	16.9ns	0.602	0.00634	3.8 KB

Benchmarks.Trace.Asm.AppSecEncoderBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Gen 1	Allocated
master	`EncodeArgs`	net6.0	37.5μs	26.1ns	101ns	0.451	0	32.4 KB
master	`EncodeArgs`	netcoreapp3.1	54.7μs	14.7ns	54.9ns	0.435	0	32.4 KB
master	`EncodeArgs`	net472	67.8μs	43.9ns	164ns	5.16	0.0679	32.5 KB
master	`EncodeLegacyArgs`	net6.0	75.8μs	385ns	1.72μs	0	0	2.14 KB
master	`EncodeLegacyArgs`	netcoreapp3.1	105μs	425ns	1.53μs	0	0	2.14 KB
master	`EncodeLegacyArgs`	net472	156μs	102ns	396ns	0.317	0	2.15 KB
#6386	`EncodeArgs`	net6.0	37.9μs	24.8ns	96ns	0.454	0	32.4 KB
#6386	`EncodeArgs`	netcoreapp3.1	55μs	26.1ns	97.6ns	0.436	0	32.4 KB
#6386	`EncodeArgs`	net472	67.7μs	54.3ns	210ns	5.16	0.0679	32.5 KB
#6386	`EncodeLegacyArgs`	net6.0	69.3μs	19.5ns	75.4ns	0	0	2.14 KB
#6386	`EncodeLegacyArgs`	netcoreapp3.1	106μs	262ns	1.01μs	0	0	2.15 KB
#6386	`EncodeLegacyArgs`	net472	156μs	80.7ns	313ns	0.31	0	2.15 KB

Benchmarks.Trace.Asm.AppSecWafBenchmark - Same speed ✔️ Same allocations ✔️

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`RunWafRealisticBenchmark`	net6.0	182μs	159ns	616ns	0	2.44 KB
master	`RunWafRealisticBenchmark`	netcoreapp3.1	194μs	128ns	461ns	0	2.39 KB
master	`RunWafRealisticBenchmark`	net472	207μs	50.4ns	189ns	0.309	2.46 KB
master	`RunWafRealisticBenchmarkWithAttack`	net6.0	122μs	60.4ns	234ns	0	1.47 KB
master	`RunWafRealisticBenchmarkWithAttack`	netcoreapp3.1	130μs	182ns	703ns	0	1.46 KB
master	`RunWafRealisticBenchmarkWithAttack`	net472	140μs	58.1ns	217ns	0.21	1.49 KB
#6386	`RunWafRealisticBenchmark`	net6.0	182μs	106ns	409ns	0	2.44 KB
#6386	`RunWafRealisticBenchmark`	netcoreapp3.1	195μs	195ns	757ns	0	2.39 KB
#6386	`RunWafRealisticBenchmark`	net472	209μs	86.9ns	325ns	0.311	2.46 KB
#6386	`RunWafRealisticBenchmarkWithAttack`	net6.0	122μs	287ns	1.11μs	0	1.47 KB
#6386	`RunWafRealisticBenchmarkWithAttack`	netcoreapp3.1	129μs	177ns	686ns	0	1.46 KB
#6386	`RunWafRealisticBenchmarkWithAttack`	net472	139μs	53.8ns	186ns	0.209	1.49 KB

Benchmarks.Trace.Iast.StringAspectsBenchmark - Same speed ✔️ More allocations ⚠️

More allocations ⚠️ in #6386

Benchmark	Base Allocated	Diff Allocated	Change	Change %
Benchmarks.Trace.Iast.StringAspectsBenchmark.StringConcatAspectBenchmark‑net6.0	253.6 KB	264.82 KB	11.22 KB	4.43%

Fewer allocations 🎉 in #6386

Benchmark	Base Allocated	Diff Allocated	Change	Change %
Benchmarks.Trace.Iast.StringAspectsBenchmark.StringConcatBenchmark‑net472	59.6 KB	59.07 KB	-528 B	-0.89%

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Allocated
master	`StringConcatBenchmark`	net6.0	62.5μs	729ns	7.25μs	43.44 KB
master	`StringConcatBenchmark`	netcoreapp3.1	54.4μs	187ns	673ns	42.64 KB
master	`StringConcatBenchmark`	net472	38μs	67.7ns	253ns	59.6 KB
master	`StringConcatAspectBenchmark`	net6.0	307μs	1.38μs	6.62μs	253.6 KB
master	`StringConcatAspectBenchmark`	netcoreapp3.1	347μs	1.71μs	11.2μs	253.34 KB
master	`StringConcatAspectBenchmark`	net472	290μs	5.46μs	53.2μs	278.53 KB
#6386	`StringConcatBenchmark`	net6.0	57.9μs	714ns	7.11μs	43.44 KB
#6386	`StringConcatBenchmark`	netcoreapp3.1	53.9μs	219ns	846ns	42.64 KB
#6386	`StringConcatBenchmark`	net472	38.9μs	184ns	688ns	59.07 KB
#6386	`StringConcatAspectBenchmark`	net6.0	313μs	1.62μs	9.74μs	264.82 KB
#6386	`StringConcatAspectBenchmark`	netcoreapp3.1	350μs	1.95μs	12.8μs	254.56 KB
#6386	`StringConcatAspectBenchmark`	net472	278μs	5.71μs	55.4μs	278.53 KB

andrewlock · 2024-12-03T14:53:20Z

Benchmarks Report for tracer 🐌

Benchmarks for #6386 compared to master:

3 benchmarks are slower, with geometric mean 1.142
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.99μs	44.2ns	290ns	0.0159	0.00797	0	5.61 KB
master	`StartStopWithChild`	netcoreapp3.1	10μs	54.9ns	325ns	0.0192	0.00959	0	5.8 KB
master	`StartStopWithChild`	net472	16.3μs	43.1ns	155ns	1.04	0.301	0.095	6.2 KB
#6386	`StartStopWithChild`	net6.0	7.96μs	43.3ns	237ns	0.0155	0.00777	0	5.61 KB
#6386	`StartStopWithChild`	netcoreapp3.1	9.93μs	55.2ns	374ns	0.0249	0.00995	0	5.79 KB
#6386	`StartStopWithChild`	net472	16.3μs	47.1ns	183ns	1.06	0.326	0.0897	6.22 KB

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

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`WriteAndFlushEnrichedTraces`	net6.0	483μs	244ns	945ns	0	2.7 KB
master	`WriteAndFlushEnrichedTraces`	netcoreapp3.1	691μs	257ns	963ns	0	2.7 KB
master	`WriteAndFlushEnrichedTraces`	net472	860μs	472ns	1.83μs	0.431	3.3 KB
#6386	`WriteAndFlushEnrichedTraces`	net6.0	486μs	253ns	980ns	0	2.7 KB
#6386	`WriteAndFlushEnrichedTraces`	netcoreapp3.1	669μs	237ns	885ns	0	2.7 KB
#6386	`WriteAndFlushEnrichedTraces`	net472	843μs	348ns	1.3μs	0.425	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	149μs	852ns	6.32μs	0.146	14.47 KB
master	`SendRequest`	netcoreapp3.1	166μs	959ns	8.13μs	0.167	17.27 KB
master	`SendRequest`	net472	0.00049ns	0.000366ns	0.00132ns	0	0 b
#6386	`SendRequest`	net6.0	151μs	906ns	8.92μs	0.14	14.47 KB
#6386	`SendRequest`	netcoreapp3.1	164μs	944ns	7.56μs	0.154	17.27 KB
#6386	`SendRequest`	net472	0.00238ns	0.000807ns	0.00302ns	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	566μs	2.91μs	14.9μs	0.584	0	0	41.6 KB
master	`WriteAndFlushEnrichedTraces`	netcoreapp3.1	670μs	3.21μs	18.7μs	0.338	0	0	41.73 KB
master	`WriteAndFlushEnrichedTraces`	net472	862μs	3.65μs	13.7μs	8.39	2.52	0.419	53.36 KB
#6386	`WriteAndFlushEnrichedTraces`	net6.0	573μs	2.3μs	8.92μs	0.563	0	0	41.7 KB
#6386	`WriteAndFlushEnrichedTraces`	netcoreapp3.1	645μs	1.44μs	5.56μs	0.321	0	0	41.77 KB
#6386	`WriteAndFlushEnrichedTraces`	net472	840μs	2.12μs	7.91μs	8.39	2.52	0.419	53.23 KB

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

Slower ⚠️ in #6386

Benchmark	diff/base	Base Median (ns)	Diff Median (ns)	Modality
Benchmarks.Trace.DbCommandBenchmark.ExecuteNonQuery‑net6.0	1.119	1,220.66	1,366.14

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Gen 1	Allocated
master	`ExecuteNonQuery`	net6.0	1.22μs	1.07ns	4.13ns	0.014	0	1.02 KB
master	`ExecuteNonQuery`	netcoreapp3.1	1.8μs	0.87ns	3.37ns	0.0135	0	1.02 KB
master	`ExecuteNonQuery`	net472	2.13μs	2.96ns	11.1ns	0.157	0.00107	987 B
#6386	`ExecuteNonQuery`	net6.0	1.37μs	1.48ns	5.73ns	0.0142	0	1.02 KB
#6386	`ExecuteNonQuery`	netcoreapp3.1	1.78μs	1.52ns	5.89ns	0.0133	0	1.02 KB
#6386	`ExecuteNonQuery`	net472	2.12μs	1.83ns	6.85ns	0.156	0.00106	987 B

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

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`CallElasticsearch`	net6.0	1.2μs	0.364ns	1.41ns	0.0138	976 B
master	`CallElasticsearch`	netcoreapp3.1	1.57μs	0.718ns	2.78ns	0.0132	976 B
master	`CallElasticsearch`	net472	2.5μs	2.23ns	8.33ns	0.157	995 B
master	`CallElasticsearchAsync`	net6.0	1.18μs	0.475ns	1.84ns	0.0135	952 B
master	`CallElasticsearchAsync`	netcoreapp3.1	1.73μs	0.943ns	3.27ns	0.0138	1.02 KB
master	`CallElasticsearchAsync`	net472	2.66μs	2.42ns	9.38ns	0.167	1.05 KB
#6386	`CallElasticsearch`	net6.0	1.2μs	0.688ns	2.66ns	0.0138	976 B
#6386	`CallElasticsearch`	netcoreapp3.1	1.55μs	0.97ns	3.76ns	0.0131	976 B
#6386	`CallElasticsearch`	net472	2.62μs	1.86ns	7.21ns	0.158	995 B
#6386	`CallElasticsearchAsync`	net6.0	1.29μs	2.04ns	7.92ns	0.0135	952 B
#6386	`CallElasticsearchAsync`	netcoreapp3.1	1.59μs	1.14ns	4.42ns	0.0135	1.02 KB
#6386	`CallElasticsearchAsync`	net472	2.66μs	1.17ns	4.52ns	0.167	1.05 KB

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

Slower ⚠️ in #6386

Benchmark	diff/base	Base Median (ns)	Diff Median (ns)	Modality
Benchmarks.Trace.GraphQLBenchmark.ExecuteAsync‑net6.0	1.122	1,157.51	1,298.67

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`ExecuteAsync`	net6.0	1.16μs	0.62ns	2.4ns	0.0134	952 B
master	`ExecuteAsync`	netcoreapp3.1	1.73μs	0.717ns	2.78ns	0.013	952 B
master	`ExecuteAsync`	net472	1.87μs	0.35ns	1.35ns	0.145	915 B
#6386	`ExecuteAsync`	net6.0	1.3μs	2.13ns	8.26ns	0.0129	952 B
#6386	`ExecuteAsync`	netcoreapp3.1	1.65μs	0.631ns	2.44ns	0.0124	952 B
#6386	`ExecuteAsync`	net472	1.82μs	0.504ns	1.89ns	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.55μs	1.77ns	6.87ns	0.0315	2.31 KB
master	`SendAsync`	netcoreapp3.1	5.21μs	1.37ns	5.32ns	0.0393	2.85 KB
master	`SendAsync`	net472	7.35μs	2.75ns	10.6ns	0.495	3.12 KB
#6386	`SendAsync`	net6.0	4.39μs	2.4ns	9.29ns	0.033	2.31 KB
#6386	`SendAsync`	netcoreapp3.1	5.28μs	5.57ns	21.6ns	0.0368	2.85 KB
#6386	`SendAsync`	net472	7.31μs	1.24ns	4.65ns	0.494	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.49μs	2.42ns	9.37ns	0.0227	1.64 KB
master	`EnrichedLog`	netcoreapp3.1	2.24μs	0.95ns	3.42ns	0.0223	1.64 KB
master	`EnrichedLog`	net472	2.5μs	1.65ns	6.39ns	0.249	1.57 KB
#6386	`EnrichedLog`	net6.0	1.46μs	0.969ns	3.75ns	0.0233	1.64 KB
#6386	`EnrichedLog`	netcoreapp3.1	2.19μs	1.4ns	5.24ns	0.022	1.64 KB
#6386	`EnrichedLog`	net472	2.63μs	0.962ns	3.6ns	0.249	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	121μs	187ns	726ns	0	0	4.28 KB
master	`EnrichedLog`	netcoreapp3.1	123μs	135ns	503ns	0	0	4.28 KB
master	`EnrichedLog`	net472	151μs	191ns	738ns	0.676	0.225	4.46 KB
#6386	`EnrichedLog`	net6.0	120μs	101ns	391ns	0.0605	0	4.28 KB
#6386	`EnrichedLog`	netcoreapp3.1	124μs	113ns	421ns	0	0	4.28 KB
#6386	`EnrichedLog`	net472	152μs	137ns	513ns	0.685	0.228	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.02μs	1.04ns	4.03ns	0.03	2.2 KB
master	`EnrichedLog`	netcoreapp3.1	4.34μs	1.15ns	4.13ns	0.0303	2.2 KB
master	`EnrichedLog`	net472	4.98μs	1.63ns	6.32ns	0.319	2.02 KB
#6386	`EnrichedLog`	net6.0	3.07μs	1.1ns	4.27ns	0.0308	2.2 KB
#6386	`EnrichedLog`	netcoreapp3.1	4.14μs	1.23ns	4.75ns	0.029	2.2 KB
#6386	`EnrichedLog`	net472	5.04μs	2.02ns	7.82ns	0.319	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.35μs	1.12ns	4.35ns	0.0163	1.14 KB
master	`SendReceive`	netcoreapp3.1	1.8μs	2.06ns	7.98ns	0.0152	1.14 KB
master	`SendReceive`	net472	2.14μs	1.71ns	6.62ns	0.184	1.16 KB
#6386	`SendReceive`	net6.0	1.39μs	0.926ns	3.34ns	0.0161	1.14 KB
#6386	`SendReceive`	netcoreapp3.1	1.73μs	2.27ns	8.81ns	0.0155	1.14 KB
#6386	`SendReceive`	net472	2.11μs	1.37ns	4.92ns	0.184	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.85μs	1.96ns	7.6ns	0.0228	1.6 KB
master	`EnrichedLog`	netcoreapp3.1	3.98μs	1.25ns	4.83ns	0.022	1.65 KB
master	`EnrichedLog`	net472	4.35μs	1.7ns	6.14ns	0.323	2.04 KB
#6386	`EnrichedLog`	net6.0	2.75μs	1.87ns	7.25ns	0.0221	1.6 KB
#6386	`EnrichedLog`	netcoreapp3.1	3.9μs	2.46ns	9.55ns	0.0214	1.65 KB
#6386	`EnrichedLog`	net472	4.45μs	3.07ns	11.9ns	0.323	2.04 KB

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

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`StartFinishSpan`	net6.0	393ns	0.736ns	2.85ns	0.00805	576 B
master	`StartFinishSpan`	netcoreapp3.1	589ns	1.02ns	3.94ns	0.00795	576 B
master	`StartFinishSpan`	net472	598ns	1.58ns	6.12ns	0.0918	578 B
master	`StartFinishScope`	net6.0	475ns	0.628ns	2.43ns	0.00977	696 B
master	`StartFinishScope`	netcoreapp3.1	735ns	0.963ns	3.73ns	0.00951	696 B
master	`StartFinishScope`	net472	868ns	2.36ns	9.14ns	0.105	658 B
#6386	`StartFinishSpan`	net6.0	398ns	0.641ns	2.48ns	0.00812	576 B
#6386	`StartFinishSpan`	netcoreapp3.1	564ns	0.875ns	3.39ns	0.00782	576 B
#6386	`StartFinishSpan`	net472	643ns	0.926ns	3.59ns	0.0917	578 B
#6386	`StartFinishScope`	net6.0	476ns	0.388ns	1.5ns	0.00978	696 B
#6386	`StartFinishScope`	netcoreapp3.1	711ns	1.17ns	4.36ns	0.00928	696 B
#6386	`StartFinishScope`	net472	839ns	2.07ns	8.02ns	0.104	658 B

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

Slower ⚠️ in #6386

Benchmark	diff/base	Base Median (ns)	Diff Median (ns)	Modality
Benchmarks.Trace.TraceAnnotationsBenchmark.RunOnMethodBegin‑net6.0	1.188	612.58	727.45

Raw results

Branch	Method	Toolchain	Mean	StdError	StdDev	Gen 0	Allocated
master	`RunOnMethodBegin`	net6.0	612ns	1.01ns	3.9ns	0.00959	696 B
master	`RunOnMethodBegin`	netcoreapp3.1	868ns	1.87ns	7.22ns	0.0092	696 B
master	`RunOnMethodBegin`	net472	1.14μs	2.3ns	8.89ns	0.104	658 B
#6386	`RunOnMethodBegin`	net6.0	728ns	1.25ns	4.51ns	0.00973	696 B
#6386	`RunOnMethodBegin`	netcoreapp3.1	951ns	1.57ns	6.09ns	0.00918	696 B
#6386	`RunOnMethodBegin`	net472	1.07μs	2.84ns	11ns	0.104	658 B

andrewlock · 2024-12-03T18:35:27Z

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 (6386) (11.279M)   : 0, 11278575
    master (11.204M)   : 0, 11203778
    benchmarks/2.9.0 (11.033M)   : 0, 11032866

    section Automatic
    This PR (6386) (7.215M)   : 0, 7215185
    master (7.331M)   : 0, 7330853
    benchmarks/2.9.0 (7.786M)   : 0, 7785853

    section Trace stats
    master (7.519M)   : 0, 7518727

    section Manual
    master (11.261M)   : 0, 11260993

    section Manual + Automatic
    This PR (6386) (6.816M)   : 0, 6815703
    master (6.666M)   : 0, 6665502

    section DD_TRACE_ENABLED=0
    master (10.167M)   : 0, 10167088

gantt
    title Throughput Linux arm64 (Total requests) 
    dateFormat  X
    axisFormat %s
    section Baseline
    This PR (6386) (9.681M)   : 0, 9681215
    master (9.521M)   : 0, 9520567
    benchmarks/2.9.0 (9.495M)   : 0, 9494821

    section Automatic
    This PR (6386) (6.478M)   : 0, 6478154
    master (6.372M)   : 0, 6371730

    section Trace stats
    master (6.726M)   : 0, 6725555

    section Manual
    master (9.500M)   : 0, 9500374

    section Manual + Automatic
    This PR (6386) (5.966M)   : 0, 5965655
    master (6.088M)   : 0, 6087765

    section DD_TRACE_ENABLED=0
    master (8.948M)   : 0, 8948240

gantt
    title Throughput Windows x64 (Total requests) 
    dateFormat  X
    axisFormat %s
    section Baseline
    This PR (6386) (10.034M)   : 0, 10034284
    master (9.993M)   : 0, 9992988
    benchmarks/2.9.0 (10.020M)   : 0, 10019592

    section Automatic
    This PR (6386) (6.399M)   : 0, 6398646
    master (6.486M)   : 0, 6486065
    benchmarks/2.9.0 (7.255M)   : 0, 7255257

    section Trace stats
    master (7.145M)   : 0, 7145458

    section Manual
    master (10.073M)   : 0, 10072872

    section Manual + Automatic
    This PR (6386) (5.814M)   : 0, 5814153
    master (6.084M)   : 0, 6083938

    section DD_TRACE_ENABLED=0
    master (9.408M)   : 0, 9407738

## Summary of changes - Delete the tracer settings snapshot source generator - Delete the snapshot objects ## Reason for change We used these for tracking when customers use config in code so we know which properties they're changing. However, in v3 we explicitly set the values ourselves in the `ConfigureIntegration` so we may as well do all the work there ## Implementation details - Delete the source generator - Delete usages of `[GenerateSnapshot]`, `[IgnoreForSnapshot]`, and `[ConfigKey]` - Delete `TracerSettingsSnapshot` and associated files and usages - Record config changes in `ConfigureIntegration` ## Test coverage Added a simple basic assertion to the manual instrumentation tests to assert that we're still recording the `code` origin ## Other details This is step 1 of a whole load of post-v3 code cleanup 😄 - #6370 👈 This PR - #6376 - #6385 - #6386 - #6397 - #6399

…6385) ## Summary of changes Remove `PublicApiTests.PublicApiHasNotChanged` for Datadog.Trace.dll ## Reason for change The public API surface of Datadog.Trace is not _really_ public any more, as it's not directly referenced, so these tests are largely unneccessary. As of right now, `public` vs `internal` is essentially irrelevant in this project. ## Implementation details Remove the `PublicApiHasNotChanged` test. The other public API tests e.g. `AssemblyReferencesHaveNotChanged` _are_ still relevant, so jumped through some hoops to keep them ## Test coverage Slightly less now. ## Other details Part of stack - #6370 - #6376 - #6385 👈 This PR - #6386 - #6397 - #6399 - #6400 - #6405

… public

…e -> IConfigurationSource Renamed some public APIs (we don't need to split the usages any more, these aren't _actually_ public) Removed unneeded internal

Use this implementation in CustomSettingsForTests

…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

@tonyredondo

…tead of mutating (#6399) ## Summary of changes Change how CI Visibility creates its `TracerSettings` object to avoid mutating settings afterwards ## Reason for change This stack of changes is about removing duplication (among other things) in the `TracerSettings` etc related objects. This is _partially_ required in order to remove the "snapshot generator" complexity that was removed in #6370. Given `TracerSettings` are not exposed publicly in Datadog.Trace, we want to move to doing a "one shot" configuring of them, ultimately so that we can make the object immutable (and remove `ImmutableTracerSettings` and friends). ## Implementation details CI Visibility is one of the few places where we mutate settings _after_ creating the `TracerSettings`. This is mostly because there's additional logic that CI Visibility wants to perform. Ultimately, the "solution" to that issue in this PR is to move that logic into the `TracerSettings` constructor. I'm not entirely happy about it, but it's the only approach I could find that works. - Add a "dummy" configuration value to a configuration source when creating the `TracerSettings`. This is used purely as a "switch" to say "we're in CI Visibility mode". - We absolutely could just pass this in as a constructor parameter. I went that route first and then backed away, but can totally be swayed. - Add an additional configuration source to update settings that we want to change in CI Vis (e.g. logs injection). - In the `TracerSettings` ctor, add an additional ignored URL when in CI Vis mode, modify the default service name (if required) and add an additional GlobalTag. ## Test coverage I'd love to have some, but the CI Visibility configuration is kinda all over the place, so if you have any pointers @tonyredondo I'm all ears... ## Other details Part of stack - #6370 - #6376 - #6385 - #6386 - #6397 - #6399 👈 This PR - #6400 - #6405 - #6408

…utableDirectLogSubmissionSettings` (#6400) ## Summary of changes Merge `DirectLogSubmissionSettings` with `ImmutableDirectLogSubmissionSettings` ## Reason for change There was never really a good reason for having these as separate types. It was primarily to make testing a little easier and to mirror the `TracerSettings`/`ImmutableTracerSettings` dichotomy, but as that's going away, this is just unnecessary complexity ## Implementation details - Moved the additional logic that was previously inside `ImmutableDirectLogSubmissionSettings` into `DirectLogSubmissionSettings` - Renamed the `DirectLogSubmissionSettings` properties to match the "Immutable" version (and remove the unnecessary prefix) - Replace all usages of `Immutable*` with `DirectLogSubmissionSettings` - Move `Immutable*Tests` into appropriate file and tweak - Replace mutations with initialization (using `IConfigurationSource`) ## Test coverage Essentially the same. I removed/tweaked some tests that are no longer relevant ## Other details Part of stack - #6370 - #6376 - #6385 - #6386 - #6397 - #6399 - #6400 👈 This PR - #6405 - #6408 - #6415

…tegrationSettings` (#6405) ## Summary of changes Merge `IntegrationSettings` with `ImmutableIntegrationSettings` ## Reason for change This stack of PRs is about doing one-shot configuration instead of mutation. We never mutate these in the tracer after creation, so there's no need for the separate types. ## Implementation details - Moved additional logic (handling `DisabledNames` that was previously inside `ImmutableIntegrationSettings` into `IntegrationSettings` - Replace all usages of `Immutable*` with `IntegrationSettings` - Move `Immutable*Tests` into appropriate file and tweak - Replace mutations with initialization - Reorder initialization of `DisabledIntegrationNames` in `TracerSettings` so that it can be used in the `IntegrationSettings` constructor ## Test coverage All covered by existing details ## Other details Part of Stack - #6370 - #6376 - #6385 - #6386 - #6397 - #6399 - #6400 - #6405 👈 This PR - #6408 - #6415

…terSettings` (#6408) ## Summary of changes Merge `ExporterSettings` with `ImmutableExporterSettings` ## Reason for change This stack of PRs is about doing one-shot configuration instead of mutation. We never mutate these in the tracer after creation, so there's no need for the separate types. ## Implementation details - Made the properties in `ExporterSettings` get-only. This required quite a lot of work because we were doing a lot of mutating of the settings in the "helper" functions. - I only _lightly_ refactored those methods (as much as possible) to avoid setting the properties in the functions and instead returning the details to set later. - These are prime candidates for some _much_ heavier refactoring later, but I didn't want to get bogged down with that in this PR - Replace all usages of `Immutable*` with `ExporterSettings` - Replace usages of `AgentUriInternal` with `AgentUri` - Move `Immutable*Tests` into appropriate file and tweak - Replace mutations with initialization ## Test coverage All covered by existing details ## Other details Part of Stack - #6370 - #6376 - #6385 - #6386 - #6397 - #6399 - #6400 - #6405 - #6408 👈 This PR - #6415

…ettings` (#6415) ## Summary of changes Merge `TracerSettings` with `ImmutableTracerSettings` ## Reason for change This stack of PRs is about doing one-shot configuration instead of mutation. We never mutate these in the tracer after creation, so there's no need for the separate types. ## Implementation details - Make the properties in `TracerSettings` get-only. - Make the collections in `TracerSettings` readonly. - Move logic that used to be in the constructor of `ImmutableTracerSettings` into `TracerSettings` - e.g. Service/Version/Env were being changed based on DD_TAGS values. Moved that to TracerSettings and (importantly) added missing telemetry recording of these values. - Added missing recording of _effective_ `DisabledInstegrations` - Moving this logic caused some _tests_ to be broken (checking default values). Updated the expected values of those tests in a single - Replace all usages of `ImmutableTracerSettings` with `TracerSettings` - Move `ITracer` to Datadog.Trace.Manual - It's only used there, and references the manual-version of `ImmutableTracerSettings` which we _want_ to keep. - Move `Immutable*Tests` into appropriate file and tweak - Replace mutations with initialization in tests ## Test coverage All covered by existing tests (I hope) 🤞 ## Other details There's still a _lot_ of scope to improve this Part of Stack - #6370 - #6376 - #6385 - #6386 - #6397 - #6399 - #6400 - #6405 - #6408 - #6415 👈 This PR

## Summary of changes - Delete the tracer settings snapshot source generator - Delete the snapshot objects ## Reason for change We used these for tracking when customers use config in code so we know which properties they're changing. However, in v3 we explicitly set the values ourselves in the `ConfigureIntegration` so we may as well do all the work there ## Implementation details - Delete the source generator - Delete usages of `[GenerateSnapshot]`, `[IgnoreForSnapshot]`, and `[ConfigKey]` - Delete `TracerSettingsSnapshot` and associated files and usages - Record config changes in `ConfigureIntegration` ## Test coverage Added a simple basic assertion to the manual instrumentation tests to assert that we're still recording the `code` origin ## Other details This is step 1 of a whole load of post-v3 code cleanup 😄 - #6370 👈 This PR - #6376 - #6385 - #6386 - #6397 - #6399

## Summary of changes Delete the Public API Generator ## Reason for change We added this generator to reduce the amount of boilerplate you need to write to correctly record telemetry for public APIs. However, with the move to Datadog.Trace.Manual, these APIs are completely unused, so we may as well remove the complexity and duplication. ## Implementation details - Delete the `[GeneratePublicApi]` generator - Keeping the `[PublicApi]` attribute for now - that will be cleared up in a separate PR - Rename the previously-decorated properties that _were_ called `SomePropInternal` to `SomeProp` - We still have some "leftover" `Internal` suffixes, will tidy those up separately - Main changes are in `TracerSettings`, `ExporterSettings`, `IntegrationSettings` + their immutable counterparts ## Test coverage Covered by existing tests ## Other details I noticed that there were some properties that we were getting public API telemetry for which we kind of lost in the move to Datadog.Trace.Manual: `SpanContext.Parent`, `SpanContext.ParentId`, `SpanContext.ServiceName`. I don't _think_ that actually matters, as these can't actually be accessed any more for technical reasons... Part of stack - #6370 - #6376 👈 This PR - #6385 - #6386 - #6397 - #6399 - #6405

…6385) ## Summary of changes Remove `PublicApiTests.PublicApiHasNotChanged` for Datadog.Trace.dll ## Reason for change The public API surface of Datadog.Trace is not _really_ public any more, as it's not directly referenced, so these tests are largely unneccessary. As of right now, `public` vs `internal` is essentially irrelevant in this project. ## Implementation details Remove the `PublicApiHasNotChanged` test. The other public API tests e.g. `AssemblyReferencesHaveNotChanged` _are_ still relevant, so jumped through some hoops to keep them ## Test coverage Slightly less now. ## Other details Part of stack - #6370 - #6376 - #6385 👈 This PR - #6386 - #6397 - #6399 - #6400 - #6405

## Summary of changes - Delete legacy `IConfigurationSource` - Rename `ITelmeteredConfigurationSource` => `IConfigurationSource` - Remove some "public" API workarounds - Make some APIs `public` instead of `internal` (just to satisfy compiler) - Fix tests ## Reason for change `ITelmeteredConfigurationSource` was introduced when `IConfigurationSource` was public, and so could not be changed. We have since removed that interface from the public API (it's not in `Datadog.trace.Manual`) so now it simply adds confusion and complexity (as it should _not_ be used internally in Datadog.Trace). ## Implementation details This PR looks more complex than it is, because in order to replace all the usages of the old `IConfigurationSource` with the new one, I had to mark some other APIs public (and document them to satisfy the analyzers). It is mostly - Delete legacy `IConfigurationSource` - Rename `ITelmeteredConfigurationSource` => `IConfigurationSource` - Fix any errors I took the opportunity to also remove some of the `*Internal` methods which were used to avoid calling the "public" APIs; seeing as these aren't _actually_ public any more, that's just unnecessary duplication. ## Test coverage The testing was a pain. The `ConfigurationBuilder` tests were all designed to check that `ITelmeteredConfigurationSource` gave the same results as `IConfigurationSource` (while never _explicitly_ specifying what the "expected" behaviour was. I took some time to enumerate the _actual_ expected values for the `NameValueCollection` source, but the `Json` source has very different behaviour that is more of a pain to test, so I chose to simplify a lot there. We could do a _lot_ to clean up those tests, but I didn't want to add even more complexity in this PR. ## Other details To help "fix" the ASM tests I introduced a `DictionaryObjectConfigurationSource`, in which you pass in a `Dictionary<string, object>`. This is useful for testing (as it was previously used) but is actually going to be useful for a future clean-up PR too, so I kept it in Datadog.Trace instead of in the test project. Part of stack - #6370 - #6376 - #6385 - #6386 👈 This PR - #6397 - #6399 - #6400 - #6405 - #6408

…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

@tonyredondo

…tead of mutating (#6399) ## Summary of changes Change how CI Visibility creates its `TracerSettings` object to avoid mutating settings afterwards ## Reason for change This stack of changes is about removing duplication (among other things) in the `TracerSettings` etc related objects. This is _partially_ required in order to remove the "snapshot generator" complexity that was removed in #6370. Given `TracerSettings` are not exposed publicly in Datadog.Trace, we want to move to doing a "one shot" configuring of them, ultimately so that we can make the object immutable (and remove `ImmutableTracerSettings` and friends). ## Implementation details CI Visibility is one of the few places where we mutate settings _after_ creating the `TracerSettings`. This is mostly because there's additional logic that CI Visibility wants to perform. Ultimately, the "solution" to that issue in this PR is to move that logic into the `TracerSettings` constructor. I'm not entirely happy about it, but it's the only approach I could find that works. - Add a "dummy" configuration value to a configuration source when creating the `TracerSettings`. This is used purely as a "switch" to say "we're in CI Visibility mode". - We absolutely could just pass this in as a constructor parameter. I went that route first and then backed away, but can totally be swayed. - Add an additional configuration source to update settings that we want to change in CI Vis (e.g. logs injection). - In the `TracerSettings` ctor, add an additional ignored URL when in CI Vis mode, modify the default service name (if required) and add an additional GlobalTag. ## Test coverage I'd love to have some, but the CI Visibility configuration is kinda all over the place, so if you have any pointers @tonyredondo I'm all ears... ## Other details Part of stack - #6370 - #6376 - #6385 - #6386 - #6397 - #6399 👈 This PR - #6400 - #6405 - #6408

…utableDirectLogSubmissionSettings` (#6400) ## Summary of changes Merge `DirectLogSubmissionSettings` with `ImmutableDirectLogSubmissionSettings` ## Reason for change There was never really a good reason for having these as separate types. It was primarily to make testing a little easier and to mirror the `TracerSettings`/`ImmutableTracerSettings` dichotomy, but as that's going away, this is just unnecessary complexity ## Implementation details - Moved the additional logic that was previously inside `ImmutableDirectLogSubmissionSettings` into `DirectLogSubmissionSettings` - Renamed the `DirectLogSubmissionSettings` properties to match the "Immutable" version (and remove the unnecessary prefix) - Replace all usages of `Immutable*` with `DirectLogSubmissionSettings` - Move `Immutable*Tests` into appropriate file and tweak - Replace mutations with initialization (using `IConfigurationSource`) ## Test coverage Essentially the same. I removed/tweaked some tests that are no longer relevant ## Other details Part of stack - #6370 - #6376 - #6385 - #6386 - #6397 - #6399 - #6400 👈 This PR - #6405 - #6408 - #6415

…tegrationSettings` (#6405) ## Summary of changes Merge `IntegrationSettings` with `ImmutableIntegrationSettings` ## Reason for change This stack of PRs is about doing one-shot configuration instead of mutation. We never mutate these in the tracer after creation, so there's no need for the separate types. ## Implementation details - Moved additional logic (handling `DisabledNames` that was previously inside `ImmutableIntegrationSettings` into `IntegrationSettings` - Replace all usages of `Immutable*` with `IntegrationSettings` - Move `Immutable*Tests` into appropriate file and tweak - Replace mutations with initialization - Reorder initialization of `DisabledIntegrationNames` in `TracerSettings` so that it can be used in the `IntegrationSettings` constructor ## Test coverage All covered by existing details ## Other details Part of Stack - #6370 - #6376 - #6385 - #6386 - #6397 - #6399 - #6400 - #6405 👈 This PR - #6408 - #6415

…terSettings` (#6408) ## Summary of changes Merge `ExporterSettings` with `ImmutableExporterSettings` ## Reason for change This stack of PRs is about doing one-shot configuration instead of mutation. We never mutate these in the tracer after creation, so there's no need for the separate types. ## Implementation details - Made the properties in `ExporterSettings` get-only. This required quite a lot of work because we were doing a lot of mutating of the settings in the "helper" functions. - I only _lightly_ refactored those methods (as much as possible) to avoid setting the properties in the functions and instead returning the details to set later. - These are prime candidates for some _much_ heavier refactoring later, but I didn't want to get bogged down with that in this PR - Replace all usages of `Immutable*` with `ExporterSettings` - Replace usages of `AgentUriInternal` with `AgentUri` - Move `Immutable*Tests` into appropriate file and tweak - Replace mutations with initialization ## Test coverage All covered by existing details ## Other details Part of Stack - #6370 - #6376 - #6385 - #6386 - #6397 - #6399 - #6400 - #6405 - #6408 👈 This PR - #6415

…ettings` (#6415) Merge `TracerSettings` with `ImmutableTracerSettings` This stack of PRs is about doing one-shot configuration instead of mutation. We never mutate these in the tracer after creation, so there's no need for the separate types. - Make the properties in `TracerSettings` get-only. - Make the collections in `TracerSettings` readonly. - Move logic that used to be in the constructor of `ImmutableTracerSettings` into `TracerSettings` - e.g. Service/Version/Env were being changed based on DD_TAGS values. Moved that to TracerSettings and (importantly) added missing telemetry recording of these values. - Added missing recording of _effective_ `DisabledInstegrations` - Moving this logic caused some _tests_ to be broken (checking default values). Updated the expected values of those tests in a single - Replace all usages of `ImmutableTracerSettings` with `TracerSettings` - Move `ITracer` to Datadog.Trace.Manual - It's only used there, and references the manual-version of `ImmutableTracerSettings` which we _want_ to keep. - Move `Immutable*Tests` into appropriate file and tweak - Replace mutations with initialization in tests All covered by existing tests (I hope) 🤞 There's still a _lot_ of scope to improve this Part of Stack - #6370 - #6376 - #6385 - #6386 - #6397 - #6399 - #6400 - #6405 - #6408 - #6415 👈 This PR

andrewlock added area:tracer The core tracer library (Datadog.Trace, does not include OpenTracing, native code, or integrations) area:tests unit tests, integration tests type:refactor type:cleanup Minor code clean up labels Dec 3, 2024

andrewlock requested review from a team as code owners December 3, 2024 12:01

This was referenced Dec 3, 2024

Remove PublicApiTests.PublicApiHasNotChanged for Datadog.Trace.dll #6385

Merged

Remove old generated public APIs #6376

Merged

Remove settings snapshot generator #6370

Merged

andrewlock force-pushed the andrew/simplify-configuration-sources branch from ac95deb to 6448274 Compare December 3, 2024 13:22

This was referenced Dec 4, 2024

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

Merged

[CI Visibility] Set TracerSettings using a configuration source instead of mutating #6399

Merged

andrewlock force-pushed the andrew/remove-public-api-tests branch from 09408bc to fb1c403 Compare December 5, 2024 09:53

andrewlock requested review from a team as code owners December 5, 2024 09:53

andrewlock force-pushed the andrew/simplify-configuration-sources branch from 6448274 to ce085e6 Compare December 5, 2024 09:53

andrewlock mentioned this pull request Dec 5, 2024

Make DirectLogSubmissionSettings properly immutable and remove ImmutableDirectLogSubmissionSettings #6400

Merged

andrewlock force-pushed the andrew/remove-public-api-tests branch from fb1c403 to 964d182 Compare December 5, 2024 12:51

andrewlock force-pushed the andrew/simplify-configuration-sources branch from ce085e6 to 1cc4bb6 Compare December 5, 2024 12:52

andrewlock mentioned this pull request Dec 5, 2024

Make IntegrationSettings properly immutable and remove ImmutableIntegrationSettings #6405

Merged

kevingosse approved these changes Dec 5, 2024

View reviewed changes

robertpi approved these changes Dec 6, 2024

View reviewed changes

andrewlock force-pushed the andrew/remove-public-api-tests branch from 964d182 to 8afed3b Compare December 6, 2024 11:49

andrewlock force-pushed the andrew/simplify-configuration-sources branch from 1cc4bb6 to c68e10c Compare December 6, 2024 11:49

Base automatically changed from andrew/remove-public-api-tests to master December 6, 2024 14:08

andrewlock added 4 commits December 6, 2024 14:09

Change visibility so that we can make ITelemeteredConfigurationSource…

b4330ee

… public

Delete IConfigurationSource and rename ITelemeteredConfigurationSourc…

150a1ca

…e -> IConfigurationSource Renamed some public APIs (we don't need to split the usages any more, these aren't _actually_ public) Removed unneeded internal

Add TelemetryErrorCode geared towards dict configuration source

b427f5b

Add a DictionaryObjectConfigurationSource that doesn't do conversions

3b52a69

Use this implementation in CustomSettingsForTests

andrewlock force-pushed the andrew/simplify-configuration-sources branch from c68e10c to 3b52a69 Compare December 6, 2024 14:10

andrewlock mentioned this pull request Dec 6, 2024

Make ExporterSettings properly immutable and remove ImmutableExporterSettings #6408

Merged

andrewlock merged commit 5e7b556 into master Dec 6, 2024
101 of 105 checks passed

andrewlock deleted the andrew/simplify-configuration-sources branch December 6, 2024 16:22

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

andrewlock mentioned this pull request Dec 10, 2024

Make TracerSettings properly immutable and remove ImmutableTracerSettings #6415

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Simplify duplication in `IConfigurationSource` #6386

Simplify duplication in `IConfigurationSource` #6386

andrewlock commented Dec 3, 2024 •

edited

Loading

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

More allocations ⚠️ in #6386

Fewer allocations 🎉 in #6386

Raw results

andrewlock commented Dec 3, 2024 •

edited

Loading

Raw results

Raw results

Raw results

Raw results

Slower ⚠️ in #6386

Raw results

Raw results

Slower ⚠️ in #6386

Raw results

Raw results

Raw results

Raw results

Raw results

Raw results

Raw results

Raw results

Slower ⚠️ in #6386

Raw results

andrewlock commented Dec 3, 2024 •

edited

Loading

Simplify duplication in IConfigurationSource #6386

Simplify duplication in IConfigurationSource #6386

Conversation

andrewlock commented Dec 3, 2024 • edited Loading

Summary of changes

Reason for change

Implementation details

Test coverage

Other details

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

Datadog Report

andrewlock commented Dec 3, 2024 • edited Loading

Execution-Time Benchmarks Report ⏱️

andrewlock commented Dec 3, 2024 • edited Loading

Benchmarks Report for appsec 🐌

Benchmark details

Raw results

Raw results

Raw results

More allocations ⚠️ in #6386

Fewer allocations 🎉 in #6386

Raw results

andrewlock commented Dec 3, 2024 • edited Loading

Benchmarks Report for tracer 🐌

Benchmark details

Raw results

Raw results

Raw results

Raw results

Slower ⚠️ in #6386

Raw results

Raw results

Slower ⚠️ in #6386

Raw results

Raw results

Raw results

Raw results

Raw results

Raw results

Raw results

Raw results

Slower ⚠️ in #6386

Raw results

andrewlock commented Dec 3, 2024 • edited Loading

Throughput/Crank Report ⚡

Simplify duplication in `IConfigurationSource` #6386

Simplify duplication in `IConfigurationSource` #6386

andrewlock commented Dec 3, 2024 •

edited

Loading

datadog-ddstaging bot commented Dec 3, 2024 •

edited

Loading

andrewlock commented Dec 3, 2024 •

edited

Loading

andrewlock commented Dec 3, 2024 •

edited

Loading

andrewlock commented Dec 3, 2024 •

edited

Loading

andrewlock commented Dec 3, 2024 •

edited

Loading