-
Notifications
You must be signed in to change notification settings - Fork 150
Fix calls to IsIntegrationEnabled(), IsErrorStatusCode(), and GetIntegrationAnalyticsSampleRate()
#7544
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix calls to IsIntegrationEnabled(), IsErrorStatusCode(), and GetIntegrationAnalyticsSampleRate()
#7544
Conversation
This comment has been minimized.
This comment has been minimized.
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.8)
dateFormat X
axisFormat %s
todayMarker off
section Bailout
This PR (7544) - mean (75ms) : 73, 77
. : milestone, 75,
master - mean (75ms) : 73, 76
. : milestone, 75,
section Baseline
This PR (7544) - mean (70ms) : 68, 72
. : milestone, 70,
master - mean (70ms) : 68, 73
. : milestone, 70,
section CallTarget+Inlining+NGEN
This PR (7544) - mean (1,053ms) : 1015, 1091
. : milestone, 1053,
master - mean (1,072ms) : 991, 1152
. : milestone, 1072,
gantt
title Execution time (ms) FakeDbCommand (.NET Core 3.1)
dateFormat X
axisFormat %s
todayMarker off
section Bailout
This PR (7544) - mean (110ms) : 108, 113
. : milestone, 110,
master - mean (110ms) : 107, 113
. : milestone, 110,
section Baseline
This PR (7544) - mean (109ms) : 106, 112
. : milestone, 109,
master - mean (109ms) : 105, 113
. : milestone, 109,
section CallTarget+Inlining+NGEN
This PR (7544) - mean (750ms) : 727, 772
. : milestone, 750,
master - mean (753ms) : 725, 780
. : milestone, 753,
gantt
title Execution time (ms) FakeDbCommand (.NET 6)
dateFormat X
axisFormat %s
todayMarker off
section Bailout
This PR (7544) - mean (97ms) : 95, 99
. : milestone, 97,
master - mean (97ms) : 95, 100
. : milestone, 97,
section Baseline
This PR (7544) - mean (97ms) : 95, 100
. : milestone, 97,
master - mean (97ms) : 93, 101
. : milestone, 97,
section CallTarget+Inlining+NGEN
This PR (7544) - mean (717ms) : 675, 760
. : milestone, 717,
master - mean (712ms) : 687, 737
. : milestone, 712,
gantt
title Execution time (ms) FakeDbCommand (.NET 8)
dateFormat X
axisFormat %s
todayMarker off
section Bailout
This PR (7544) - mean (97ms) : 95, 100
. : milestone, 97,
master - mean (97ms) : 95, 99
. : milestone, 97,
section Baseline
This PR (7544) - mean (96ms) : 93, 99
. : milestone, 96,
master - mean (96ms) : 93, 98
. : milestone, 96,
section CallTarget+Inlining+NGEN
This PR (7544) - mean (669ms) : 654, 684
. : milestone, 669,
master - mean (677ms) : 664, 690
. : milestone, 677,
gantt
title Execution time (ms) HttpMessageHandler (.NET Framework 4.8)
dateFormat X
axisFormat %s
todayMarker off
section Bailout
This PR (7544) - mean (196ms) : 193, 200
. : milestone, 196,
master - mean (196ms) : 193, 198
. : milestone, 196,
section Baseline
This PR (7544) - mean (192ms) : 188, 196
. : milestone, 192,
master - mean (192ms) : 188, 197
. : milestone, 192,
section CallTarget+Inlining+NGEN
This PR (7544) - mean (1,174ms) : 1098, 1251
. : milestone, 1174,
master - mean (1,168ms) : 1109, 1226
. : milestone, 1168,
gantt
title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
dateFormat X
axisFormat %s
todayMarker off
section Bailout
This PR (7544) - mean (277ms) : 273, 281
. : milestone, 277,
master - mean (276ms) : 274, 279
. : milestone, 276,
section Baseline
This PR (7544) - mean (279ms) : 271, 287
. : milestone, 279,
master - mean (276ms) : 270, 283
. : milestone, 276,
section CallTarget+Inlining+NGEN
This PR (7544) - mean (936ms) : 892, 980
. : milestone, 936,
master - mean (946ms) : 905, 986
. : milestone, 946,
gantt
title Execution time (ms) HttpMessageHandler (.NET 6)
dateFormat X
axisFormat %s
todayMarker off
section Bailout
This PR (7544) - mean (270ms) : 267, 274
. : milestone, 270,
master - mean (270ms) : 265, 276
. : milestone, 270,
section Baseline
This PR (7544) - mean (270ms) : 266, 274
. : milestone, 270,
master - mean (269ms) : 265, 274
. : milestone, 269,
section CallTarget+Inlining+NGEN
This PR (7544) - mean (925ms) : 876, 974
. : milestone, 925,
master - mean (928ms) : 884, 973
. : milestone, 928,
gantt
title Execution time (ms) HttpMessageHandler (.NET 8)
dateFormat X
axisFormat %s
todayMarker off
section Bailout
This PR (7544) - mean (269ms) : 265, 273
. : milestone, 269,
master - mean (269ms) : 264, 274
. : milestone, 269,
section Baseline
This PR (7544) - mean (268ms) : 264, 272
. : milestone, 268,
master - mean (270ms) : 266, 273
. : milestone, 270,
section CallTarget+Inlining+NGEN
This PR (7544) - mean (848ms) : 827, 870
. : milestone, 848,
master - mean (861ms) : 844, 878
. : milestone, 861,
|
b443332 to
8bd2ecc
Compare
## Summary of changes - Extract a `MutableSettings` type from `TracerSettings` - Extract a `Raw` type from `ExporterSettings` ## Reason for change We're working on refactoring how we handle dynamic/remote/config in code settings i.e. settings which can change at runtime. As a first step, this PR extracts those settings to their own type, called `MutableSettings` because they mutable during the lifetime of the app. > Feel free to suggest other names for this type, or we can alternatively bikeshed it later. Additionally, extracted the "raw" settings from `ExporterSettings`. These are the values which are read from config sources. The actual values of `ExporterSettings` are set based on these values, using a highly convoluted (backward compatible) series of methods, but the idea is: if the `Raw` settings haven't changed, the `ExporterSettings` haven't changed. > This isn't _strictly_ true due to the `File.Exists` call we have, but I believe this is good enough for our purposes. ## Implementation details - Create `MutableSettings` and move all the properties from `TracerSettings` that _can_ change to it. - Update `TracerSettings` to create an instance of `MutableSettings`, and simply pass-through properties to it. - This should mean existing functionality is unaffected by this PR - Implement `IEquatable<MutableSettings>` for future comparisons between `MutableSettings` instances - Unfortunately, can't use a `record` here or auto-gen the implementation, because we need to handle equivalence of the dictionaries. - Extract the "raw" setting reading to an `ExporterSettings` nested-type - Opted for nested here, because unlike `MutableSettings` (which will eventually live separately from `TracerSettings`) we won't expose `Raw` to consumers - they'll still use `ExporterSettings` ## Test coverage This is just a refactoring, so it's covered by existing tests. Additionally, I added a test for the `IEquatable` implementation (which is similar to the test we have for `ImmutableDynamicSettings`) to ensure the implementation is updated if we add more properties. ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-819 Part of a config stack - #7522 👈 - #7525 - #7530 - #7532 - #7543 - #7544
8bd2ecc to
2614b47
Compare
d582594 to
5c72ac5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Codex Review: Here are some suggestions.
Lines 63 to 68 in 2614b47
| internal static CallTargetState CreateSenderSpan<TTarget>(TTarget instance, string operationName = "azure_servicebus.send", IEnumerable? messages = null) | |
| where TTarget : IServiceBusSender, IDuckType | |
| { | |
| var tracer = Tracer.Instance; | |
| if (!tracer.Settings.IsIntegrationEnabled(IntegrationId.AzureServiceBus, false)) | |
| { |
[P0] Remove remaining uses of TracerSettings.IsIntegrationEnabled
The refactor removes the helper methods from TracerSettings, but the Azure Service Bus instrumentation still calls tracer.Settings.IsIntegrationEnabled(...) here and in ServiceBusReceiverReceiveMessagesAsyncIntegration and AzureFunctionsCommon. Because the method no longer exists, these files will fail to compile. Switch these remaining call sites to MutableSettings (tracer.CurrentTraceSettings.Settings.IsIntegrationEnabled(...)) as done elsewhere in the commit.
Reply with @codex fix comments to fix any unresolved comments.
About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you open a pull request for review, mark a draft as ready, or comment "@codex review". If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex fix this CI failure" or "@codex address that feedback".
b08c4d7 to
ab87da2
Compare
5c72ac5 to
f9243ce
Compare
3642a15 to
5b84dfc
Compare
bebdded to
df9dec1
Compare
## Summary of changes Rebuild and re-assign `MutableSettings` when dynamic config (remote or config in code) changes. ## Reason for change This is part of a general stack to extract the "mutable" configuration from static config that is fixed for the lifetime of the app. In the [previous PR](#7522) we moved mutable settings to their own type, but otherwise left things unchanged and just rebuilt everything whenever anything changes. In this PR we move towards combining the dynamic/code configuration, handling changes by _only_ rebuilding the `MutableSettings` (not `TracerSettings`) and handling all the fallout that causes for telemetry. This is very much still a "stop gap"; we still rebuild everything (_except_ the `TracerSettings` object) when these settings changes. ## Implementation details - Create "global" config sources for dynamic settings and code settings - There's actually a bug today where we clobber dynamic settings if we change things in code because we're not storing the sources globally. - When dynamic config or config in code changes - Create a new `MutableSettings` object based only on dynamic sources (with a fallback for the "static" values) - For config in code, we also check for changes to `ExporterSettings` - If there's no discernable changes, bail out - no need to tear down the world - If there _are_ changes, Mutate `TracerSettings`, and do the normal "reconfigure everything" - Remove the (now unused `ImmutableDynamicSettingsTests`) Note that there are technically some behaviour changes in this PR: - `useDefaultSources: false` only ignores env vars etc for values that can be set through code. Other settings will always use the default sources. - `StatsComutationEnabled` can not be _set_ via code. ## Test coverage This is still all technically a "refactoring", so should be covered by existing tests 🤞 ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-819 Part of a config stack - #7522 - #7652 - #7525 👈 - #7530 - #7532 - #7543 - #7544
5b84dfc to
13c0a66
Compare
df9dec1 to
8ef1b0e
Compare
## Summary of changes - Expose `DefaultServiceName` on `MutableSettings` instead of on `TracerManager` - Expose `MutableSettings` on `PerTraceSettings` ## Reason for change The `DefaultServiceName` depends on `ServiceName`, which can change at runtime, so `MutableSettings` seems like the best place for it (eventually we will only have a single `TracerManager` and `TracerSettings` per lifetime > Note that this also solves an existing edge-case bug when customers do config in code and already-finished traces are serialized with the "incorrect" default service name. ## Implementation details Mostly commit-by-commit but: - Move the "fallback application name" calculation to a helper class - Expose the fallback application name on `TracerSettings` - Created as a `Lazy<>` because this calculation can be kind of expensive, and isn't necessary if the customer specifies a service name. - Exposed on `TracerSettings` because it doesn't change - Expose `DefaultServiceName` on `MutableSettings` instead of `TracerManager`. - Update usages to point to the new location Additionally, there are some places where I believe we were "incorrectly" using the `DD_SERVICE` value, and ignoring the real fallback name. - [x] Service Discovery's `StoreTracerMetadata` - @anna-git can you confirm if I'm correct that this _should_ be using the "calculated" service name as a fallback? - [x] `TraceExporterConfiguration` - @ganeshnj, same question, can you confirm that we should be passing the "calculated" service name, not just the "explictly set" service name? One additional aspect I think we should consider: - Currently we're calling `NormalizeService(serviceName)` in a few places. Is there any reason we shouldn't be _always_ normalizing the service name? - e.g. why don't we normalize `DefaultServiceName` automatically? ## Test coverage Covered by existing tests generally ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-819 Part of a config stack - #7522 - #7525 - #7530 👈 - #7532 - #7543 - #7544
13c0a66 to
2f6f374
Compare
8ef1b0e to
b3dd98e
Compare
## Summary of changes Don't pass a `Tracer` instance to `PerTraceSettings.GetServiceName()` (as it's not required) ## Reason for change Cleanup/simplify the code. #7530 exposes `MutableSettings` and `DefaultServiceName` on `PerTraceSettings`. Reading `DefaultServiceName` was the only reason `GetServiceName()` took a `Tracer`, so this is now uneccessary. ## Implementation details - Use `MutableSettings.DefaultServiceName` directly inside `PerTraceSettings.GetServiceName()` - Stop passing in `Tracer` instance - Cleanup usages ## Test coverage Covered by existing, just a refactoring ## Other details Could have done it as part of #7530 but trying to keep things small! https://datadoghq.atlassian.net/browse/LANGPLAT-819 Part of a config stack - #7522 - #7525 - #7530 - #7532 👈 - #7543 - #7544
2f6f374 to
8525a3e
Compare
b3dd98e to
c758157
Compare
…ropriate (#7543) ## Summary of changes Fix usages of `Tracer.Instance.Settings` to use `Tracer.Instance.CurrentTracerSettings.Settings` where appropriate ## Reason for change This PR "fixes" the places that were previously grabbing the environment/service etc from `TracerSettings` to use the `MutableSettings` exposed via `CurrentTracerSettings` instead, as the location where these settings will ultimately exist. This is effectively still just a refactoring, but prepares for the point where these settings aren't exposed on `TracerSettings` at all. The updates in this PR are for cases where you _don't_ have long-lived services, and rather need to do ad-hoc `Tracer.Instance` grabbing of the setting values in a global context. Note too that many of these places _could_ be updated in the future to subscribe to changes if that provides performance benefits. Also note that I elected not to change most calls to `IsIntegrationEnabled()` etc in this PR as there are hundreds of locations. The follow up PR handles that Also found a few cases that were incorrectly assuming that these values cannot change. Marked them with 'TODO: Subscribe to changes in settings' ## Implementation details - Mostly find and replace to use `CurrentTracerSettings.Settings` - Occasional extraction of a variable where it makes sense to avoid repeated access - Functionally identical currently (where `MutableSettings` is replaced on `TracerSettings`) but will be a required change once we stop replacing `TracerManager`. ## Test coverage Covered by existing tests ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-819 Part of a config stack - #7522 - #7525 - #7530 - #7532 - #7543 👈 - #7544
…unctions to use MutableSettings directly
8525a3e to
bc4d1ed
Compare
…ndows (#7721) ## Summary of changes Enforces that you can't _change_ the `AgentUri` to be a UDS Uri if you're on Windows ## Reason for change The trace exporter doesn't work with UDS on Windows, so we have a check in `TracerSettings` that disables the pipeline if we find this scenario. However, user's can still _change_ the agent URI at runtime in code (😭). We currently assume that the data pipeline won't be toggled at runtime (we _do_ allow for reconfiguring it in general, but not for completely removing or reintroducing). Changing this to allow the scenario would be a pain, so instead this PR blocks you from setting a UDS URI in code if you're on Windows. The good news is that as far as I can tell, noone does this today, so while _technically_ it could be considered a breaking change, I think it's ok. ## Implementation details - Throw an `ArgumentException` in the Datadog.Trace.Manual library, if you're on Windows (or .NET FX) and you try to set a UDS agent URI (using the same "detection" we do in `ExporterSettings`. - Add a check in the Instrumentation of `Tracer.Configure()` to make sure it hasn't slipped through. This could happen if a customer was using an old version of the Datadog.Trace NuGet package with a newer version of auto instrumentation. Note that this adds two additional framework references for .NET Core 3.1+, to check if we're on Windows. ## Test coverage Added an extra step to the manual instrumentation integration test to confirm we throw ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-819 Part of a config stack - #7522 - #7525 - #7530 - #7532 - #7543 - #7544 - #7721 👈 - #7722 - #7695 - #7723 - #7724
## Summary of changes Add a helper for comparing `ReadOnlyDictionary<>` instances ## Reason for change As part of the config work, we need to detect if tags have changed when customers do a manual/remote config update. This helper makes it easy ## Implementation details Added a `SequenceEqual` extension method. Note that I used `SequenceEqual` because it _already_ exists in _System.Linq_, but I could see an argument that it's too easy to use the wrong one, and instead we could use a different name? `IsSameAs(other)`? Also, I only wrote this for `ReadOnlyDictionary<>` because that's all we need, it's what we use for all our setting dictionaries, and it will be (a tiny bit) faster than making it `IDictionary<>`, but happy to change if people feel strongly. ## Test coverage Added unit tests ## Other details https://datadoghq.atlassian.net/browse/LANGPLAT-819 Part of a config stack - #7522 - #7525 - #7530 - #7532 - #7543 - #7544 - #7721 - #7722 👈 - #7695 - #7723 - #7724 --------- Co-authored-by: Steven Bouwkamp <[email protected]>
Summary of changes
Fix usages of
IsIntegrationEnabled(),IsErrorStatusCode(), andGetIntegrationAnalyticsSampleRate()to useMutableSettingsinstead ofTracerSettingsReason for change
These functions are dependent on
MutableSettings, and are exposed there, so making sure we call the methods there, and remove the delegation fromTracerSettingsentirely.Implementation details
Test coverage
Just a refactor, so covered by existing tests
Other details
https://datadoghq.atlassian.net/browse/LANGPLAT-819
Part of a config stack
MutableSettingsfromTracerSettings#7522MutableSettingson dynamic config changes #7525DefaultServiceNametoMutableSettings#7530PerTraceSettings.GetServiceName()#7532TracerSettingsto useMutableSettingswhere appropriate #7543IsIntegrationEnabled(),IsErrorStatusCode(), andGetIntegrationAnalyticsSampleRate()#7544 👈SettingsManagerfor managing mutable settings and ExporterSettings #7695