Sentry Structured Logging for .NET

https://develop.sentry.dev/sdk/telemetry/logs/

Sentry is adding support for structured logging. Let's add it to the .NET SDK!

Define the logs protocol and log envelope item in the SDK
Add the Public API (SDK options and methods) as per the docs
Make sure the the SDK follows the documented behavior
Attach default attributes to the SDK as per docs
Instrument popular logging libraries to send logs to Sentry. SDK maintainers can best decide what they should support, but we should definitely support the same integrations that we do in the SDK (NLog, Serilog, etc.)
Create a GH discussion that contains instructions for setting up the SDK in your repo. Eventually this will be moved into the primary docs. See the JS SDK's GH discussion for inspiration.

The idea is to:

Ship the barebone Sentry API into the core Sentry package
Make this work from Microsoft.Extensions.Logging
Make this work from Serilog
Make this work from NLog
Make this work from log4net

I'll dare to say that no one in .NET will use "Sentry's logging API". I know I wouldn't. But that's not the point.
The point is to have the API in the main SDK, so that the logging libraries integrations only pipe data to it.

The order above allows us to try/test things incrementally.
Once we get to n2, we can add it to nuget-trends and symbol-collector for dogfooding.

All our current logging integrations do:

Check level, if higher than MininumEventLevel it records an event
Check level, if higher than MinimumBreadcrumbLevel it adds a breadcrumb

e.g:

sentry-dotnet/src/Sentry.Extensions.Logging/SentryLogger.cs

Lines 39 to 86 in 084e3b4

    
           public void Log<TState>( 
        
               LogLevel logLevel, 
        
               EventId eventId, 
        
               TState state, 
        
               Exception? exception, 
        
               Func<TState, Exception?, string>? formatter) 
        
           { 
        
               if (!IsEnabled(logLevel)) 
        
               { 
        
                   return; 
        
               } 
        
               var message = formatter?.Invoke(state, exception); 
        
               if (ShouldCaptureEvent(logLevel, eventId, exception)) 
        
               { 
        
                   var @event = CreateEvent(logLevel, eventId, state, exception, message, CategoryName); 
        
                   _ = _hub.CaptureEvent(@event); 
        
                   // Capturing exception events adds a breadcrumb automatically... we don't want to add another one 
        
                   if (exception != null) 
        
                   { 
        
                       return; 
        
                   } 
        
               } 
        
               if (ShouldAddBreadcrumb(logLevel, eventId, exception)) 
        
               { 
        
                   var data = eventId.ToDictionaryOrNull(); 
        
                   if (exception != null && message != null) 
        
                   { 
        
                       // Exception.Message won't be used as Breadcrumb message 
        
                       // Avoid losing it by adding as data: 
        
                       data ??= new Dictionary<string, string>(); 
        
                       data.Add("exception_message", exception.Message); 
        
                   } 
        
                   _hub.AddBreadcrumb( 
        
                       _clock, 
        
                       (message ?? exception?.Message)!, 
        
                       CategoryName, 
        
                       null, 
        
                       data, 
        
                       logLevel.ToBreadcrumbLevel()); 
        
               } 
        
           }

The crumb goes after, so that in a subsequent event, it will include the breadcrumb of the previous event.

This works well for error monitoring. But with the new logging integration, we'll send all logs to Sentry.
The new logging could be a new logger class, that's added in of logging is enabled. Since little is shared from the current logger described above, and the new one.

Sentry Structured Logging for .NET

Add Sentry-Logger APIs
- See https://develop.sentry.dev/sdk/telemetry/logs/
Integration: Sentry.Extensions.Logging
- public CaptureLog on IHub and ISentryClient
- and/or internal Extension-Methods receiving IHub and ISentryClient
- ensure SDK-Name/Version is set correctly, test via Sentry.AspNetCore and Sentry.Maui
- see also feat(logs): initial API for Sentry Logs #4158 (comment)
more buffering for Sentry.Extensions.Logging
- add support for the new Microsoft.Extensions.Logging.Abstractions.IBufferedLogger interface
- next to the original Microsoft.Extensions.Logging.ILogger
Integration: Sentry.AspNetCore
Integration: Sentry.AspNetCore.Blazor.WebAssembly
Integration: Sentry.Azure.Functions.Worker
Integration: Sentry.Maui
Integration: Sentry.Serilog
Integration: Sentry.NLog
Integration: Sentry.Log4Net
Internal APIs for Sentry.Unity
- via internal Extension-Methods receiving IHub and ISentryClient
Processing: Batching / Priority
- see also feat(logs): initial API for Sentry Logs #4158 (comment)
- see also feat(logs): initial API for Sentry Logs #4158 (comment)
Sentry-Logger-API: Accelerator overloads for convenience
- see also feat(logs): initial API for Sentry Logs #4158 (comment)
Sentry-Logger-API: Generic overloads
- 3 overloads (with 1, 2 and 3 generic arguments) per Log{Level} method
- to avoid both boxing and array allocations when EnableLogs is false
- see also feat(logs): initial API for Sentry Logs #4158 (comment)
Sentry-Logger-API: [InterpolatedStringHandler]
Documentation
- see also feat(logs): initial API for Sentry Logs #4158 (comment)

Hey,

Thanks for this feature that are you working on. Any plans to adapt opentelemetry for logs as you did for tracing?

@wondertalik

Hey @wondertalik - thanks for your interest! At the current moment we are focusing on adding logs support via the Sentry SDKs. We'll evaluate OpenTelemetry support in the future. Our logs schema is a superset of the OpenTelemetry schema, so we are already compatible with OpenTelemetry.

Hi there, awesome work on the Sentry log integration so far!

In my apps I have a logging section in the appsettings.json file. However, I still see many log messages that I don't expect based on the configuration below in Sentry. Do I need to configure the log level separately in the Sentry SDK? I did see a SentryLoggingOptions.ExperimentalLogging.MinimumLogLevel property. Are we expected to set that property instead of the built-in log level settings in ASP.NET Core?

  "Logging": {
    "LogLevel": {
      "MyApp": "Trace",
      "Default": "Warning",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  }

With 5.x yes ... there is indeed the option SentryLoggingOptions.ExperimentalLogging.MinimumLogLevel.
However, this solution does not allow for per-category-name based granularity.
This option is (very soon: was) a workaround.

With the upcoming 6.0.0 (next couple of days), this option will be gone and our Microsoft.Extensions.Logging for Sentry Structured Logs will properly respect Configuration like appsettings.json, appsettings.{HostEnvironment}.json and also programmatic Configuration like builder.Logging.AddFilter(null, LogLevel) and builder.Logging.AddFilter("My.Category.Name", LogLevel).

The reason we had to do this in a major version is that there is a behavioral breaking change involved, as we noticed inconsistencies during implementation.
For more details on that see #4700.
The TL;DR; is:

6.0.0 is fixing inconsistencies of filtering within all of Sentry's Microsoft.Extensions.Logging-based integrations, to be not only as originally intended, but also idiomatic across the ecosystem
- Breadcrumbs are filtered by
  1. SentryLoggingOptions.MinimumBreadcrumbLevel
  2. SentryLoggingOptions.AddLogEntryFilter
  3. SentryOptions.SetBeforeBreadcrumb
- Events are filtered by
  1. SentryLoggingOptions.MinimumEventLevel
  2. SentryLoggingOptions.AddLogEntryFilter
  3. SentryOptions.SetBeforeSend
- Logs are filtered by
  1. Configuration as mentioned above
  2. SentryOptions.SetBeforeSendLog

With 5.x yes ... there is indeed the option SentryLoggingOptions.ExperimentalLogging.MinimumLogLevel. However, this solution does not allow for per-category-name based granularity. This option is (very soon: was) a workaround.

With the upcoming 6.0.0 (next couple of days), this option will be gone and our Microsoft.Extensions.Logging for Sentry Structured Logs will properly respect Configuration like appsettings.json, appsettings.{HostEnvironment}.json and also programmatic Configuration like builder.Logging.AddFilter(null, LogLevel) and builder.Logging.AddFilter("My.Category.Name", LogLevel).

The reason we had to do this in a major version is that there is a behavioral breaking change involved, as we noticed inconsistencies during implementation. For more details on that see #4700. The TL;DR; is:

6.0.0 is fixing inconsistencies of filtering within all of Sentry's Microsoft.Extensions.Logging-based integrations, to be not only as originally intended, but also idiomatic across the ecosystem

Breadcrumbs are filtered by

SentryLoggingOptions.MinimumBreadcrumbLevel

SentryLoggingOptions.AddLogEntryFilter

SentryOptions.SetBeforeBreadcrumb

Events are filtered by

SentryLoggingOptions.MinimumEventLevel

SentryLoggingOptions.AddLogEntryFilter

SentryOptions.SetBeforeSend

Logs are filtered by

Configuration as mentioned above

SentryOptions.SetBeforeSendLog

Can we still set a minimum log level for MAUI App? or we have to keep using SentryOptions.SetBeforeSendLog ?
For context, prior to version 6 we were doing

options.Experimental.EnableLogs = true;
options.ExperimentalLogging.MinimumLogLevel = Microsoft.Extensions.Logging.LogLevel.Information;

I that correct?

And Im assuming now we have to do

builder.Logging.AddFilter(null, LogLevel.Information);

TL;DR: correct!

Yes, as of Sentry v6.0.0 the minimum log level is now configured idiomatically via the Microsoft.Extensions.Logging infrastructure.
SentryOptions.SetBeforeSendLog is no longer necessary to filter logs per Log-Level and/or per Category. But you may still use it to drop and/or scrub logs based on other Attributes.
And SentryLoggingOptions.ExperimentalLogging.MinimumLogLevel is no longer available.

Although .NET MAUI does not support appsettings.{Environment}.json out of the box, you could set it up yourself (with some caveats). But all other means of configuration do work out of the box, like AddFilter you mentioned, configuring the minimum log level on a per-Category basis.

e.g.

builder.Logging
  .AddFilter(null, LogLevel.Warning)
  .AddFilter("System", LogLevel.Error)
  .AddFilter("Microsoft", LogLevel.Error)
  .AddFilter("MyCategory", LogLevel.Information);

Closing this issue with the base infrastructure complete and stable.
Follow-ups for Q1 2026 are

Navigation Menu

Repository navigation

Sentry Structured Logging for .NET #4132

Sentry Structured Logging for .NET

160 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	public void Log<TState>(
	LogLevel logLevel,
	EventId eventId,
	TState state,
	Exception? exception,
	Func<TState, Exception?, string>? formatter)
	{
	if (!IsEnabled(logLevel))
	{
	return;
	}

	var message = formatter?.Invoke(state, exception);

	if (ShouldCaptureEvent(logLevel, eventId, exception))
	{
	var @event = CreateEvent(logLevel, eventId, state, exception, message, CategoryName);

	_ = _hub.CaptureEvent(@event);

	// Capturing exception events adds a breadcrumb automatically... we don't want to add another one
	if (exception != null)
	{
	return;
	}
	}

	if (ShouldAddBreadcrumb(logLevel, eventId, exception))
	{
	var data = eventId.ToDictionaryOrNull();

	if (exception != null && message != null)
	{
	// Exception.Message won't be used as Breadcrumb message
	// Avoid losing it by adding as data:
	data ??= new Dictionary<string, string>();
	data.Add("exception_message", exception.Message);
	}

	_hub.AddBreadcrumb(
	_clock,
	(message ?? exception?.Message)!,
	CategoryName,
	null,
	data,
	logLevel.ToBreadcrumbLevel());
	}
	}

Sentry Structured Logging for .NET #4132

Description

Activity

bruno-garcia commented on Apr 23, 2025

Flash0ver commented on May 15, 2025

Sentry Structured Logging for .NET

wondertalik commented on May 20, 2025

AbhiPrasad commented on May 20, 2025

160 remaining items

mvdgun commented on Dec 4, 2025

Flash0ver commented on Dec 4, 2025

Syed-RI commented on Dec 17, 2025

Flash0ver commented on Dec 23, 2025

Flash0ver commented on Dec 23, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions