Serilog: Add Processor via appSettings.json

[Mike-E-angelo]

I have the following processor:

sealed class IgnoredExceptionsAwareEventProcessor : ISentryEventProcessor
{
	public static IgnoredExceptionsAwareEventProcessor Default { get; } = new();

	IgnoredExceptionsAwareEventProcessor() : this(IgnoreException.Default) {}

	readonly ICondition<Exception> _ignore;

	public IgnoredExceptionsAwareEventProcessor(ICondition<Exception> ignore) => _ignore = ignore;

	public SentryEvent? Process(SentryEvent @event)
	{
		if (@event.Exception is {} exception)
		{
			var target = exception is AggregateException aggregate ? aggregate.GetBaseException() : exception;
			if (_ignore.Get(target) ||
			    (target.InnerException is not null && _ignore.Get(target.InnerException)))
			{
				return null;
			}
		}

		return @event;
	}
}

When I attempt to add it to WriteTo after appSettings.json is read, I get an error:

parameter.WriteTo.Sentry(x => x.AddEventProcessor(IgnoredExceptionsAwareEventProcessor.Default)

System.ArgumentNullException: 'Value cannot be null. (Parameter 'You must supply a DSN to use Sentry.To disable Sentry, pass an empty string: "".See https://docs.sentry.io/platforms/dotnet/configuration/options/#dsn')' 

Is there a known/better way of adding processors via appSettings.json? Thank you for any guidance you can provide. 🙏

[jamescrosswell]

Hey @Mike-E-angelo , there's an example of adding a custom processor in code in our samples:

sentry-dotnet/samples/Sentry.Samples.AspNetCore.Mvc/Program.cs

Lines 75 to 76 in 7111fb5

	// You can also register as many ISentryEventProcessor as you need.
	builder.Services.AddTransient<ISentryEventProcessor, ExampleEventProcessor>();

[Mike-E-angelo]

Hi @jamescrosswell thank you for your reply, it is appreciated. Can you confirm that this works in the Sentry.Serilog sink when appSettings.json is used? I have tried registering my component as denoted above but it does not get called when an exception is thrown.

[jamescrosswell]

Hi @Mike-E-angelo,

The Serilog sink delegates capturing the event to the hub:

sentry-dotnet/src/Sentry.Serilog/SentrySink.cs

Line 136 in d3d2f71

hub.CaptureEvent(evt);

So events getting captured via Serilog get handled the same way all events get handled. Even the hub is mostly just a thin wrapper around the client, which is where the processors get applied:

sentry-dotnet/src/Sentry/SentryClient.cs

Lines 356 to 360 in a2318ff

	if (SentryEventHelper.ProcessEvent(@event, scope.GetAllEventProcessors(), hint, _options, DataCategory.Error)
	is not { } processedEvent)
	{
	return SentryId.Empty; // Dropped by an event processor
	}

[Mike-E-angelo]

Thank you very much for that @jamescrosswell it is so very much appreciated. 🙏 I just realized that I was registering my processor after the ReadFrom.Configuration(). 🤦 Thank you again for taking the time to assist your users.

[Mike-E-angelo]

Doh, @jamescrosswell I thought that may be the problem, but I can confirm that my ISentryEventProcessor is being registered before ReadFrom.Configuration() but when the processors evaluate it is not in there. 🤔

Looking into this now.

[Mike-E-angelo]

OK @jamescrosswell here's what I found:

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using Sentry.Extensibility;
using Serilog;
using Serilog.Events;
using System;

namespace Sentry.Samples.AspNetCore.Serilog;

public class Program
{
    public static void Main(string[] args) => BuildWebApp(args).Run();

    public static WebApplication BuildWebApp(string[] args)
    {
        var builder = WebApplication.CreateBuilder(args);
        builder.Host.UseSerilog((_, c) =>
            c.Enrich.FromLogContext()
                .MinimumLevel.Debug()
                .WriteTo.Console().WriteTo.Debug()
                // Add Sentry integration with Serilog
                // Two levels are used to configure it.
                // One sets which log level is minimally required to keep a log message as breadcrumbs
                // The other sets the minimum level for messages to be sent out as events to Sentry
                .WriteTo.Sentry(s =>
                {
                    s.Dsn                    = SamplesShared.Default.Dsn;
                    s.MinimumBreadcrumbLevel = LogEventLevel.Debug;
                    s.MinimumEventLevel      = LogEventLevel.Error;
                }));

        // Add Sentry integration
        // It can be defined via configuration (including `appsettings.json`)
        // or coded explicitly, via parameter like:
        // .UseSentry("dsn") or .UseSentry(o => o.Dsn = ""; o.Release = "1.0"; ...)
#if !SENTRY_DSN_DEFINED_IN_ENV
        builder.WebHost.UseSentry(SamplesShared.Default.Dsn);
#else
        builder.WebHost.UseSentry(EnvironmentVariables.Dsn);
#endif
	    builder.Services.AddTransient<ISentryEventProcessor, ExampleEventProcessor>();
        // The App:
        var webApplication = builder.Build();
        Configure(webApplication);

        return webApplication;
    }

    private static void Configure(IApplicationBuilder app)
    {
        // An example ASP.NET Core middleware that throws an
        // exception when serving a request to path: /throw
        app.Use(async (context, next) =>
        {
            // See MinimumBreadcrumbLevel set at the Serilog configuration above
            Log.Logger.Debug("Static Serilog logger debug log stored as breadcrumbs.");

            var log = context.RequestServices.GetRequiredService<ILoggerFactory>()
                .CreateLogger<Program>();

            log.LogInformation("Handling some request...");
            log.LogError(new InvalidOperationException("hello?"), "This is a problem"); // <-- Never calls processor
            return;
            // Sends an event which includes the info and debug messages above
            Log.Logger.Error("Logging using static Serilog directly also goes to Sentry."); // <-- this works

            if (context.Request.Path == "/greetings")
            {
                context.Response.ContentType = "text/plain";
                await context.Response.WriteAsync("Hello, World!");
            }
            else if (context.Request.Path == "/throw")
            {
                var hub = context.RequestServices.GetRequiredService<IHub>();
                hub.ConfigureScope(s =>
                {
                    // More data can be added to the scope like this:
                    s.SetTag("Sample", "ASP.NET Core"); // indexed by Sentry
                    s.SetExtra("Extra!", "Some extra information");
                });

                // Logging through the ASP.NET Core `ILogger` while using Serilog
                log.LogInformation("Logging info...");
                log.LogWarning("Logging some warning!");

                // The following exception will be captured by the SDK and the event
                // will include the Log messages and any custom scope modifications
                // as exemplified above.
                throw new Exception("An exception thrown from the ASP.NET Core pipeline");
            }
            else
            {
                await next();
            }
        });
    }
}


public class ExampleEventProcessor : ISentryEventProcessor
{
	private readonly IHttpContextAccessor _httpContext;

	public ExampleEventProcessor(IHttpContextAccessor httpContext) => _httpContext = httpContext;

	public SentryEvent Process(SentryEvent @event)
	{
		// Here I can modify the event, while taking dependencies via DI

		@event.SetExtra("Response:HasStarted", _httpContext.HttpContext?.Response.HasStarted);
		return @event;
	}
}

This line (#68) works as expected:

Log.Logger.Error("Logging using static Serilog directly also goes to Sentry."); // <-- this works

However, this one (#65) does not and never calls the processor:

log.LogError(new InvalidOperationException("hello?"), "This is a problem"); // <-- Never calls processor

Also, for your Serilog sample, I had to add the following line because it throws an error without it:

s.Dsn                    = SamplesShared.Default.Dsn;

System.ArgumentNullException: 'Value cannot be null. (Parameter 'You must supply a DSN to use Sentry.To disable Sentry, pass an empty string: "".See https://docs.sentry.io/platforms/dotnet/configuration/options/#dsn')'

One more note here:

If I comment out this line:

builder.WebHost.UseSentry(SamplesShared.Default.Dsn);

The exception thrown at /throw does not call the ExampleEventProcessor. However, if this line is left in, ExampleEventProcessor is called. Be aware that I do not call this method in my configuration, as I am under the impression all configuration is done via WriteTo.Sentry. (It also seems redundant to call two configurators as such).

[jamescrosswell]

@Mike-E-angelo there are two different overloads of the serilog integration.

1. There's this one, which expects/needs a DSN. If you use that one then you setup both a Serilog sink to send Serilog logs through to Sentri and an instance of the Sentry SDK.
2. Then there's this one, which only configures the Serilog sink. You don't provide a DSN to this one so it's expected/needed that you initialise Sentry separately.

When using ASP.NET Core, the Sentry SDK will be initialised via the WebHost extensions (e.g. here) so you do not want to initialise it when setting up the Serilog sink. You should only initialise Serilog with a DSN if you're using Serilog in a command line application or a Background service or something (i.e. if you haven't already initialised Sentry via one of the other integrations).

This is a constant point of confusion in the SDK today, which I think we should change:

• Consider not initialising the Sdk from logging integrations #5245

[Mike-E-angelo]

Thank you for that @jamescrosswell so is the expectation then that we are supposed to be calling WebHost.Sentry call in addition to configuring the sink as well? As I mention in #5245 it seems that the sentrySerilogOptions.InitializeSdk should be getting set to true which means the SDK is initialized? Difficult to understand the installation procedures as presented.

Additionally, can you please confirm that the ISentryEventProcessor does not get called when reporting an error via ILogger.LogError above? Should we create a new issue for this? Thank you for your continued assistance and patience as I get acclimated to your SDK.

[jamescrosswell]

Difficult to understand the installation procedures as presented.

I agree... which is why we have #5245.

Whatever you do, you only want to initialize the Sentry SDK once.

• If you're doing that by calling SentryWebHostBuilderExtensions.UseSentry (per the guidelines for our ASP.NET integration) then you do not want to also initialize it via the Serilog integration.
• The way to configure Sentry's serilog integration without also (re)initializing the Sentry SDK is to use the overload of SentrySinkExtensions.Sentry that does not take a DSN as a parameter (so you don't pass the DSN when configuring the Serilog integration e.
• If you're configuring Serilog via appsettings.json, make sure you're not trying to set the DSN in the settings for the Sentry sink (so just the basic parameters, like we have in our sample)

Additionally, can you please confirm that the ISentryEventProcessor does not get called when reporting an error via ILogger.LogError above

I don't think any event processor was configured for the version of the SDK that was initialised to handle logs via ILogger.LogError... the event processor was configured on the other instance of the SDK that you initialised which is why you saw the events when using the static log methods but not when using the ILogger interface.

If you resolve the duplicate SDK initialisation problem, the event processor will start working again no matter how you log your logs.

[Mike-E-angelo]

OK @jamescrosswell I understand much better now that appSettings.json needs to have two entries. That will involve some wrangling on our end with Bicep adjustments but not a big deal long term.

However, when I attempt to follow your guidance above, with the following code the ILogger.LogError never calls the ISentryEventProcessor and seems like a bug. Here it is for your review:

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using Sentry.Extensibility;
using Serilog;
using Serilog.Events;
using System;
using System.Diagnostics;

namespace Sentry.Samples.AspNetCore.Serilog;

public class Program
{
    public static void Main(string[] args) => BuildWebApp(args).Run();

    public static WebApplication BuildWebApp(string[] args)
    {
        var builder = WebApplication.CreateBuilder(args);
        builder.WebHost.UseSentry();
        builder.Host.UseSerilog((_, c) =>
            c.Enrich.FromLogContext()
                .MinimumLevel.Debug()
                .WriteTo.Console().WriteTo.Debug()
                // Add Sentry integration with Serilog
                // Two levels are used to configure it.
                // One sets which log level is minimally required to keep a log message as breadcrumbs
                // The other sets the minimum level for messages to be sent out as events to Sentry
                .WriteTo.Sentry(minimumBreadcrumbLevel: LogEventLevel.Debug, minimumEventLevel: LogEventLevel.Error));

        builder.Services.AddTransient<ISentryEventProcessor, ExampleEventProcessor>();
        // The App:
        var webApplication = builder.Build();
        Configure(webApplication);

        return webApplication;
    }

    private static void Configure(IApplicationBuilder app)
    {
        // An example ASP.NET Core middleware that throws an
        // exception when serving a request to path: /throw
        app.Use(async (context, next) =>
        {
            // See MinimumBreadcrumbLevel set at the Serilog configuration above
            Log.Logger.Debug("Static Serilog logger debug log stored as breadcrumbs.");

            var log = context.RequestServices.GetRequiredService<ILoggerFactory>()
                .CreateLogger<Program>();

            log.LogInformation("Handling some request...");
            log.LogError(new InvalidOperationException("hello?"), "This is a problem"); // <-- Never calls processor
            // Sends an event which includes the info and debug messages above
            //Log.Logger.Error("Logging using static Serilog directly also goes to Sentry."); // <-- this works

            if (context.Request.Path == "/greetings")
            {
                context.Response.ContentType = "text/plain";
                await context.Response.WriteAsync("Hello, World!");
            }
            else if (context.Request.Path == "/throw")
            {
                /*var hub = context.RequestServices.GetRequiredService<IHub>();
                hub.ConfigureScope(s =>
                {
                    // More data can be added to the scope like this:
                    s.SetTag("Sample", "ASP.NET Core"); // indexed by Sentry
                    s.SetExtra("Extra!", "Some extra information");
                });*/

                // Logging through the ASP.NET Core `ILogger` while using Serilog
                log.LogInformation("Logging info...");
                log.LogWarning("Logging some warning!");

                // The following exception will be captured by the SDK and the event
                // will include the Log messages and any custom scope modifications
                // as exemplified above.
                throw new Exception("An exception thrown from the ASP.NET Core pipeline");
            }
            else
            {
                await next();
            }
        });
    }
}


public class ExampleEventProcessor : ISentryEventProcessor
{
	/*private readonly IHttpContextAccessor _httpContext;

	public ExampleEventProcessor(IHttpContextAccessor httpContext) => _httpContext = httpContext;*/
	public ExampleEventProcessor()
	{
		Debugger.Break();
	}

	public SentryEvent Process(SentryEvent @event)
	{
		// Here I can modify the event, while taking dependencies via DI

		// @event.SetExtra("Response:HasStarted", _httpContext.HttpContext?.Response.HasStarted);
		return @event;
	}
}

With the above code throw new Exception("An exception thrown from the ASP.NET Core pipeline"); is the only exception that is ever passed to the ExampleEventProcessor.

[jamescrosswell]

@Mike-E-angelo so that we're on the same page, could you create an issue with a minimal reproducible example of the problem you're seeing?