Repository navigation
Sentry Calls Wrong Serilog Overload #5458
Description
Package
Sentry
.NET Flavor
.NET
.NET Version
10.0.400-preview.0.26322.102
OS
Windows
OS Version
Windows 11
Development Environment
Visual Studio v18.x
Other Error Monitoring Solution
No
Other Error Monitoring Solution Name
No response
SDK Version
6.7.0
Self-Hosted Sentry Version
No response
Workload Versions
Consider the following appSettings.json:
{
"Sentry": {
"dsn": "DSN DEFINED HERE"
},
"Serilog": {
"WriteTo": [
{
"Name": "Sentry",
"Args": {
"enableLogs": true,
"environment": "Testing"
}
}
]
}
}
The problem is that since dsn is not defined in the Serilog section (since it is already defined in the Sentry section), this overload is selected:
public static LoggerConfiguration Sentry(
this LoggerSinkConfiguration loggerConfiguration,
LogEventLevel? minimumEventLevel = null,
LogEventLevel? minimumBreadcrumbLevel = null,
IFormatProvider? formatProvider = null,
ITextFormatter? textFormatter = null
)
This does not have arguments such as enableLogs and environment and because of this, the above configuration does not apply.
UseSentry or SentrySdk.Init call
builder.WebHost.UseSentry();
(Pulls from configuration)
Steps to Reproduce
Run Sentry + Serilog using the above appSettings.json
Expected Result
The provided arguments in the appSettings.json are loaded
Actual Result
The provided arguments in the appSettings.json are not loaded 💥
Activity
linear-code commentedon Jul 30, 2026
NET-778
Mike-E-angelo commentedon Jul 30, 2026
Thankfully, adding
"dsn": null,fixes this issue:It's not very obvious, and the
dsnparameter is defined as non-nullable, so it doesn't seem like it should work, but it does.Mike-E-angelo commentedon Jul 30, 2026
Nope, the saga continues. While that does call the correct override, the sdk does not get initialized, and therefore never uses it. 😅
So it would seem that the following is the correct configuration:
Mike-E-angelo commentedon Jul 30, 2026
Ok while the above works, now I am getting two entries for every log message sent. 😅😞
Fix for getsentry/sentry-dotnet#5458 (#158)
Mike-E-angelo commentedon Jul 30, 2026
I am having to do the following to omit the double write ATM. When doing the above configuration there's a message sent to the MEL and to Serilog, resulting in a double write:
DragonSpark/Framework@ad8d209#diff-b3ae48509be5e27d575f4b968ba759ce8b18df251c2a80078fb9f7b877a55884R19-R26
Obviously less than ideal, it would be great to have this fixed at the library level. 👍
jamescrosswell commentedon Aug 3, 2026
That is how it's designed to work yes. I'm not sure why you're seeing multiple messages per log though. If you've got a minimal repro for this, I could take a look into it further.
1 remaining item
github-actions commentedon Aug 3, 2026
👋 Thanks for the report! We've added the
Needs Reproductionlabel because we need a minimal reproduction to investigate further.Please provide a link to a public GitHub repository that reproduces the issue with as little code as possible. Our repro guide has tips on how to create one.
Some quick hints:
dotnet new console(or similar) projectSentrySdk.Init/UseSentrycall (with the DSN blanked out)Alternatively, if the issue only manifests in your own codebase, you could try gradually removing code until you have a minimal repro.
Mike-E-angelo commentedon Aug 4, 2026
Hi @jamescrosswell thank you very much for your patience as I figure this out. The issue has to do with the
writeToProvidersparameter in theUseSerilogoverload.I have created a sample here:
https://github.com/Mike-E-angelo/Stash/blob/issues/reported/5458/Sentry.Samples.AspNetCore.Serilog/Program.cs
When this value is
trueall registered providers (console, debug) get written to once. However, Sentry gets written twice.Please let me know if any further information is required around this issue, and I will assist you.
jamescrosswell commentedon Aug 5, 2026
Hi @Mike-E-angelo ,
This is specific to Serilog.
Sentry.AspNetCore
Our Sentry.AspNetCore integration:
In practical terms, this means the
Sentry.AspNetCoreis registering a couple of providers for you automatically:sentry-dotnet/src/Sentry.AspNetCore/SentryWebHostBuilderExtensions.cs
Lines 96 to 97 in 777cc47
One of those providers captures logs (all logs) and uses the SentryOptions to identify any that should be converted into breadcrumbs (on the scope) or errors/events (in your Sentry dashboard).
The other provider captures structured logs and the standard configuration knobs for Microsoft.Extensions.Logging control which logs will be captured as structured logs.
See #4700 for details.
Sentry.Serilog
The Sentry.Serilog integration configures a Serilog sink.
You can use Sentry.Serilog along side Sentry.AspNetCore - you won't get duplicate logs in Sentry.
With
writeToProviders: false,UseSerilogreplaces the MEL pipeline —ILoggerFactorybecomesSerilogLoggerFactoryand every registeredILoggerProvider, including both Sentry ones, is ignored entirely. MELILoggercalls flow into the Serilog pipeline and out through Serilog sinks only. The Sentry MEL providers are completely dormant... all is well in the world.However, if you set writeToProviders: true then Serilog will both send your logs to the Sentry Sink and forward them to MEL (which will also be captured by Sentry's MEL provider).
Worse, Serilog will bypass the MEL configuration so there's no way to selectively disable certain events in the MEL provider:
Recommendation
Use one or the other - but not both.
If you want to use Sentry.Serilog to capture Serilog log events, you'll need to disable
writeToProviders- otherwise you'll end up with duplicate logs in Sentry. There's no easy way to avoid that.If you want to enable
writeToProvidersin Serilog (for reasons that have nothing to do with Sentry), you could removeSentry.Serilogfrom your application and simply rely on Sentry's MEL integration (Serilog will be forwarding all logs to this anyway, in that scenario). However, since Serilog ignores the MEL configuration in this setup, the only way to filter which logs would be sent to Sentry then would be via SetBeforeSendLog... not impossible - just a bit of a pain to write and maintain (not maintained in config) and slightly wasteful - the logs go through the entire log processing pipeline (augmented with metadata etc) regardless of whether they're logs you want to capture or not.Mike-E-angelo commentedon Aug 5, 2026
Hi @jamescrosswell, thank you for that detailed analysis and reply; it is certainly appreciated. It's challenging here because I do want to use Sentry.AspNetCore and get all the benefits you describe that this enables. 🙏
For writeToProviders, by default MEL creates Console/Debug providers automatically. This is preferred because it ties into existing/default functionality. I do not want to add 2 more package Serilog sink references to accomplish something that is already there by default with MEL, if that makes sense.
As for the referenced LogLevel issue, I did run into that and addressed it yesterday, so that is not an issue on my side:
DragonSpark/Framework@7d6e19c
Finally, for the double-write issue, I do have a workaround which I suppose is OK, but it would be ideal to have this addressed in your library in some capacity:
https://github.com/DragonSpark/Framework/blob/release/v2/DragonSpark.Sentry/UseSentry.cs#L21
So, I suppose everything is working now with the above, but it would be ideal to see if we can find a way to add an option to do this instead. I understand if that is not possible. We can close this issue if that is the case. 👍
jamescrosswell commentedon Aug 5, 2026
I can't think of an easy way for us to do that in the Sentry SDK... we'd have know that:
a) You had both the Serilog and the ASP.NET Core integrations enabled
b) That you'd configured Serilog with
writeToProviders: trueThe later is particularly difficult since that's config for another SDK (that isn't exposed afaik).
Then we'd have to assume it was OK to disable capturing logs via the MEL providers...
Since this is a bit of an edge case, I think the workaround you've already found is probably the best option.
There are only two real options: