Description
An app that calls UseSentry and also builder.Logging.AddSentry() registers two sets of Sentry logger providers. UseSentry adds the host's own pair, for example SentryAspNetCoreLoggerProvider and SentryAspNetCoreStructuredLoggerProvider. Logging.AddSentry() adds SentryLoggerProvider and SentryStructuredLoggerProvider next to them. Every ILogger call then goes through both sets.
I measured it on #5642's branch with an ASP.NET Core test host from IntegrationMockedBackgroundWorker:
|
UseSentry only |
UseSentry and Logging.AddSentry() |
| Logger providers |
2 |
4 |
Events from one LogError without an exception |
1 |
2 |
Breadcrumbs from one LogInformation |
1 |
2 |
Structured logs per entry, with EnableLogs = true |
1 |
2 |
main registers the providers the same way, with AddSingleton<ILoggerProvider, …> in both UseSentry and Logging.AddSentry(), so 6.x most likely behaves the same. I didn't run it there. MAUI, Blazor WebAssembly and Google Cloud Functions register their own providers in the same way.
In a host app the second call is redundant, because UseSentry already registers the providers.
Proposal
When a host has registered Sentry's logger providers, Logging.AddSentry() shouldn't add a second set. The host's options then govern all ILogger capture. That matches #5642, where an explicit Logging.AddSentry() in a host app doesn't opt in to logs, because the integration was installed by the host and the call adds nothing the user didn't already have.
One way to do it: each host registers an internal marker service next to its providers, and Logging.AddSentry() registers its providers through factories that turn them off when the marker is there. The decision happens once, when the provider is created, so logging calls don't pay for it. A sketch of this for the structured logger provider came out of #5642.
#5572 adds a generic-host helper that will register the providers too, so the same rule should apply there.
Open question: should a redundant Logging.AddSentry() also write a diagnostic message, so people know they can remove it?
Description
An app that calls
UseSentryand alsobuilder.Logging.AddSentry()registers two sets of Sentry logger providers.UseSentryadds the host's own pair, for exampleSentryAspNetCoreLoggerProviderandSentryAspNetCoreStructuredLoggerProvider.Logging.AddSentry()addsSentryLoggerProviderandSentryStructuredLoggerProvidernext to them. EveryILoggercall then goes through both sets.I measured it on #5642's branch with an ASP.NET Core test host from
IntegrationMockedBackgroundWorker:UseSentryonlyUseSentryandLogging.AddSentry()LogErrorwithout an exceptionLogInformationEnableLogs = truemainregisters the providers the same way, withAddSingleton<ILoggerProvider, …>in bothUseSentryandLogging.AddSentry(), so 6.x most likely behaves the same. I didn't run it there. MAUI, Blazor WebAssembly and Google Cloud Functions register their own providers in the same way.In a host app the second call is redundant, because
UseSentryalready registers the providers.Proposal
When a host has registered Sentry's logger providers,
Logging.AddSentry()shouldn't add a second set. The host's options then govern allILoggercapture. That matches #5642, where an explicitLogging.AddSentry()in a host app doesn't opt in to logs, because the integration was installed by the host and the call adds nothing the user didn't already have.One way to do it: each host registers an internal marker service next to its providers, and
Logging.AddSentry()registers its providers through factories that turn them off when the marker is there. The decision happens once, when the provider is created, so logging calls don't pay for it. A sketch of this for the structured logger provider came out of #5642.#5572 adds a generic-host helper that will register the providers too, so the same rule should apply there.
Open question: should a redundant
Logging.AddSentry()also write a diagnostic message, so people know they can remove it?