Remove old generated public APIs #6376
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
andrewlock
added
area:tracer
kevingosse
approved these changes
Nov 29, 2024
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:
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 (6376) - mean (69ms) : 65, 73
. : milestone, 69,
master - mean (69ms) : 67, 71
. : milestone, 69,
section CallTarget+Inlining+NGEN
This PR (6376) - mean (981ms) : 956, 1007
. : milestone, 981,
master - mean (974ms) : 951, 996
. : milestone, 974,
gantt
title Execution time (ms) FakeDbCommand (.NET Core 3.1)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6376) - mean (108ms) : 105, 111
. : milestone, 108,
master - mean (108ms) : 106, 110
. : milestone, 108,
section CallTarget+Inlining+NGEN
This PR (6376) - mean (675ms) : 661, 689
. : milestone, 675,
master - mean (675ms) : 657, 693
. : milestone, 675,
gantt
title Execution time (ms) FakeDbCommand (.NET 6)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6376) - mean (91ms) : 89, 94
. : milestone, 91,
master - mean (91ms) : 89, 93
. : milestone, 91,
section CallTarget+Inlining+NGEN
This PR (6376) - mean (625ms) : 611, 639
. : milestone, 625,
master - mean (629ms) : 614, 643
. : milestone, 629,
gantt
title Execution time (ms) HttpMessageHandler (.NET Framework 4.6.2)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6376) - mean (192ms) : 188, 196
. : milestone, 192,
master - mean (190ms) : 186, 194
. : milestone, 190,
section CallTarget+Inlining+NGEN
This PR (6376) - mean (1,101ms) : 1072, 1130
. : milestone, 1101,
master - mean (1,090ms) : 1059, 1122
. : milestone, 1090,
gantt
title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6376) - mean (277ms) : 271, 283
. : milestone, 277,
master - mean (275ms) : 271, 280
. : milestone, 275,
section CallTarget+Inlining+NGEN
This PR (6376) - mean (872ms) : 837, 907
. : milestone, 872,
master - mean (867ms) : 841, 894
. : milestone, 867,
gantt
title Execution time (ms) HttpMessageHandler (.NET 6)
dateFormat X
axisFormat %s
todayMarker off
section Baseline
This PR (6376) - mean (266ms) : 262, 271
. : milestone, 266,
master - mean (265ms) : 261, 270
. : milestone, 265,
section CallTarget+Inlining+NGEN
This PR (6376) - mean (850ms) : 811, 889
. : milestone, 850,
master - mean (852ms) : 822, 882
. : milestone, 852,
|
Benchmarks Report for appsec 🐌Benchmarks for #6376 compared to master:
The following thresholds were used for comparing the benchmark speeds:
Allocation changes below 0.5% are ignored. Benchmark detailsBenchmarks.Trace.Asm.AppSecBodyBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.Asm.AppSecEncoderBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.Asm.AppSecWafBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.Iast.StringAspectsBenchmark - Same speed ✔️ More allocations
|
| Benchmark | Base Allocated | Diff Allocated | Change | Change % |
|---|---|---|---|---|
| Benchmarks.Trace.Iast.StringAspectsBenchmark.StringConcatBenchmark‑net472 | 57.66 KB | 62.08 KB | 4.42 KB | 7.66% |
| Benchmarks.Trace.Iast.StringAspectsBenchmark.StringConcatAspectBenchmark‑netcoreapp3.1 | 252.05 KB | 253.7 KB | 1.65 KB | 0.65% |
| Benchmark | Base Allocated | Diff Allocated | Change | Change % |
|---|---|---|---|---|
| Benchmarks.Trace.Iast.StringAspectsBenchmark.StringConcatAspectBenchmark‑net6.0 | 264.93 KB | 263.35 KB | -1.58 KB | -0.59% |
Raw results
| Branch | Method | Toolchain | Mean | StdError | StdDev | Gen 0 | Gen 1 | Gen 2 | Allocated |
|---|---|---|---|---|---|---|---|---|---|
| master | StringConcatBenchmark |
net6.0 | 63.2μs | 786ns | 7.82μs | 0 | 0 | 0 | 43.44 KB |
| master | StringConcatBenchmark |
netcoreapp3.1 | 54.4μs | 237ns | 887ns | 0 | 0 | 0 | 42.64 KB |
| master | StringConcatBenchmark |
net472 | 37.5μs | 85ns | 307ns | 0 | 0 | 0 | 57.66 KB |
| master | StringConcatAspectBenchmark |
net6.0 | 312μs | 1.22μs | 4.22μs | 0 | 0 | 0 | 264.93 KB |
| master | StringConcatAspectBenchmark |
netcoreapp3.1 | 334μs | 1.76μs | 8.63μs | 0 | 0 | 0 | 252.05 KB |
| master | StringConcatAspectBenchmark |
net472 | 287μs | 5.75μs | 55.1μs | 0 | 0 | 0 | 278.53 KB |
| #6376 | StringConcatBenchmark |
net6.0 | 59.4μs | 676ns | 6.52μs | 0 | 0 | 0 | 43.44 KB |
| #6376 | StringConcatBenchmark |
netcoreapp3.1 | 54.4μs | 269ns | 1.2μs | 0 | 0 | 0 | 42.64 KB |
| #6376 | StringConcatBenchmark |
net472 | 37.5μs | 94.8ns | 355ns | 0 | 0 | 0 | 62.08 KB |
| #6376 | StringConcatAspectBenchmark |
net6.0 | 326μs | 1.66μs | 11.5μs | 0 | 0 | 0 | 263.35 KB |
| #6376 | StringConcatAspectBenchmark |
netcoreapp3.1 | 353μs | 1.96μs | 14.7μs | 0 | 0 | 0 | 253.7 KB |
| #6376 | StringConcatAspectBenchmark |
net472 | 302μs | 6.34μs | 61.8μs | 0 | 0 | 0 | 278.53 KB |
andrewlock
force-pushed
the
andrew/remove-old-public-apis
branch
from
2d11f11 to
e9f3ed1
Compare
Datadog ReportBranch report: ✅ 0 Failed, 458474 Passed, 3568 Skipped, 34h 14m 9.52s Total Time |
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 (6376) (11.371M) : 0, 11371481
master (11.222M) : 0, 11221800
benchmarks/2.9.0 (11.033M) : 0, 11032866
section Automatic
This PR (6376) (7.281M) : 0, 7280742
master (7.306M) : 0, 7305807
benchmarks/2.9.0 (7.786M) : 0, 7785853
section Trace stats
master (7.621M) : 0, 7620774
section Manual
master (11.257M) : 0, 11257171
section Manual + Automatic
This PR (6376) (6.710M) : 0, 6709701
master (6.783M) : 0, 6782564
section DD_TRACE_ENABLED=0
master (10.363M) : 0, 10362594
gantt
title Throughput Linux arm64 (Total requests)
dateFormat X
axisFormat %s
section Baseline
This PR (6376) (9.532M) : 0, 9532288
master (9.664M) : 0, 9664098
benchmarks/2.9.0 (9.495M) : 0, 9494821
section Automatic
This PR (6376) (6.229M) : 0, 6229228
master (6.272M) : 0, 6271501
section Trace stats
master (6.601M) : 0, 6601213
section Manual
master (9.639M) : 0, 9638684
section Manual + Automatic
This PR (6376) (6.033M) : 0, 6033046
master (5.996M) : 0, 5996086
section DD_TRACE_ENABLED=0
master (8.743M) : 0, 8742779
gantt
title Throughput Windows x64 (Total requests)
dateFormat X
axisFormat %s
section Baseline
This PR (6376) (10.297M) : 0, 10297108
master (10.051M) : 0, 10050841
benchmarks/2.9.0 (10.020M) : 0, 10019592
section Automatic
This PR (6376) (6.312M) : 0, 6311950
master (6.245M) : 0, 6245212
benchmarks/2.9.0 (7.255M) : 0, 7255257
section Trace stats
master (7.094M) : 0, 7093813
section Manual
master (9.987M) : 0, 9987436
section Manual + Automatic
This PR (6376) (5.947M) : 0, 5946884
master (5.990M) : 0, 5990374
section DD_TRACE_ENABLED=0
master (9.233M) : 0, 9232530
|
Benchmarks Report for tracer 🐌Benchmarks for #6376 compared to master:
The following thresholds were used for comparing the benchmark speeds:
Allocation changes below 0.5% are ignored. Benchmark detailsBenchmarks.Trace.ActivityBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.AgentWriterBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.AspNetCoreBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.CIVisibilityProtocolWriterBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.DbCommandBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.ElasticsearchBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.GraphQLBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.HttpClientBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.ILoggerBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.Log4netBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.NLogBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.RedisBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.SerilogBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.SpanBenchmark - Slower
|
| Benchmark | diff/base | Base Median (ns) | Diff Median (ns) | Modality |
|---|---|---|---|---|
| Benchmarks.Trace.SpanBenchmark.StartFinishSpan‑net6.0 | 1.196 | 394.35 | 471.61 |
Raw results
| Branch | Method | Toolchain | Mean | StdError | StdDev | Gen 0 | Gen 1 | Gen 2 | Allocated |
|---|---|---|---|---|---|---|---|---|---|
| master | StartFinishSpan |
net6.0 | 393ns | 0.736ns | 2.85ns | 0.00805 | 0 | 0 | 576 B |
| master | StartFinishSpan |
netcoreapp3.1 | 589ns | 1.02ns | 3.94ns | 0.00795 | 0 | 0 | 576 B |
| master | StartFinishSpan |
net472 | 598ns | 1.58ns | 6.12ns | 0.0918 | 0 | 0 | 578 B |
| master | StartFinishScope |
net6.0 | 475ns | 0.628ns | 2.43ns | 0.00977 | 0 | 0 | 696 B |
| master | StartFinishScope |
netcoreapp3.1 | 735ns | 0.963ns | 3.73ns | 0.00951 | 0 | 0 | 696 B |
| master | StartFinishScope |
net472 | 868ns | 2.36ns | 9.14ns | 0.105 | 0 | 0 | 658 B |
| #6376 | StartFinishSpan |
net6.0 | 472ns | 0.528ns | 2.04ns | 0.00805 | 0 | 0 | 576 B |
| #6376 | StartFinishSpan |
netcoreapp3.1 | 621ns | 1.42ns | 5.5ns | 0.00778 | 0 | 0 | 576 B |
| #6376 | StartFinishSpan |
net472 | 609ns | 0.795ns | 3.08ns | 0.0916 | 0 | 0 | 578 B |
| #6376 | StartFinishScope |
net6.0 | 513ns | 0.821ns | 3.18ns | 0.00979 | 0 | 0 | 696 B |
| #6376 | StartFinishScope |
netcoreapp3.1 | 667ns | 1.87ns | 6.74ns | 0.00943 | 0 | 0 | 696 B |
| #6376 | StartFinishScope |
net472 | 836ns | 1.88ns | 7.27ns | 0.104 | 0 | 0 | 658 B |
Benchmarks.Trace.TraceAnnotationsBenchmark - Same speed ✔️ Same allocations ✔️
Raw results
| Branch | Method | Toolchain | Mean | StdError | StdDev | Gen 0 | Gen 1 | Gen 2 | Allocated |
|---|---|---|---|---|---|---|---|---|---|
| master | RunOnMethodBegin |
net6.0 | 612ns | 1.01ns | 3.9ns | 0.00959 | 0 | 0 | 696 B |
| master | RunOnMethodBegin |
netcoreapp3.1 | 868ns | 1.87ns | 7.22ns | 0.0092 | 0 | 0 | 696 B |
| master | RunOnMethodBegin |
net472 | 1.14μs | 2.3ns | 8.89ns | 0.104 | 0 | 0 | 658 B |
| #6376 | RunOnMethodBegin |
net6.0 | 677ns | 0.968ns | 3.75ns | 0.00979 | 0 | 0 | 696 B |
| #6376 | RunOnMethodBegin |
netcoreapp3.1 | 918ns | 1.24ns | 4.79ns | 0.00915 | 0 | 0 | 696 B |
| #6376 | RunOnMethodBegin |
net472 | 1.16μs | 2.05ns | 7.93ns | 0.105 | 0 | 0 | 658 B |
andrewlock
force-pushed
the
andrew/remove-old-public-apis
branch
from
e9f3ed1 to
ec58e9e
Compare
This was referenced Dec 3, 2024
andrewlock
added a commit
that referenced
this pull request
Dec 5, 2024
## 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
andrewlock
force-pushed
the
andrew/remove-old-public-apis
branch
from
ec58e9e to
9c080e2
Compare
Had to move the PublicApiAttribute into the project properly, but will be removed at a later point
andrewlock
force-pushed
the
andrew/remove-old-public-apis
branch
from
9c080e2 to
c34d544
Compare
tonyredondo
approved these changes
Dec 5, 2024
robertpi
approved these changes
Dec 6, 2024
andrewlock
added a commit
that referenced
this pull request
Dec 6, 2024
…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
andrewlock
added a commit
that referenced
this pull request
Dec 6, 2024
## 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
GreenMatan
reviewed
Dec 8, 2024
andrewlock
added a commit
that referenced
this pull request
Dec 9, 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
andrewlock
added a commit
that referenced
this pull request
Dec 9, 2024
…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
andrewlock
added a commit
that referenced
this pull request
Dec 10, 2024
…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
andrewlock
added a commit
that referenced
this pull request
Dec 11, 2024
…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
andrewlock
added a commit
that referenced
this pull request
Dec 11, 2024
…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
andrewlock
added a commit
that referenced
this pull request
Dec 12, 2024
…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
veerbia
pushed a commit
that referenced
this pull request
Dec 16, 2024
## 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
veerbia
pushed a commit
that referenced
this pull request
Dec 16, 2024
## 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
veerbia
pushed a commit
that referenced
this pull request
Dec 16, 2024
…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
veerbia
pushed a commit
that referenced
this pull request
Dec 16, 2024
## 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
veerbia
pushed a commit
that referenced
this pull request
Dec 16, 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
veerbia
pushed a commit
that referenced
this pull request
Dec 16, 2024
…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
veerbia
pushed a commit
that referenced
this pull request
Dec 16, 2024
…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
veerbia
pushed a commit
that referenced
this pull request
Dec 16, 2024
…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
veerbia
pushed a commit
that referenced
this pull request
Dec 16, 2024
…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
veerbia
pushed a commit
that referenced
this pull request
Dec 16, 2024
…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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[GeneratePublicApi]generator[PublicApi]attribute for now - that will be cleared up in a separate PRSomePropInternaltoSomePropInternalsuffixes, will tidy those up separatelyTracerSettings,ExporterSettings,IntegrationSettings+ their immutable counterpartsTest 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
PublicApiTests.PublicApiHasNotChangedfor Datadog.Trace.dll #6385IConfigurationSource#6386IConfigurationSource#6397TracerSettingsusing a configuration source instead of mutating #6399IntegrationSettingsproperly immutable and removeImmutableIntegrationSettings#6405ExporterSettingsproperly immutable and removeImmutableExporterSettings#6408TracerSettingsproperly immutable and removeImmutableTracerSettings#6415