How to use Serilog + Sentry + AspNetCore ?

Hi 👋 I’m trying to understand the steps involved to leverging Sentry.IO with an ASP.NET Core 2.2 website BUT using Serilog as the logging mechanism.

Currently, we’re using Serilog to log Info+ messages to <some place>: Console or <some website>. Works great.

But we’d also like to use Sentry.io as a sink for our manual errors or (unexpected) exceptions that could get thrown.

What is the trick to setting this up please?

(for bonus points, we define our serilog settings in our appsettings.xxxx.config file(s) so we don’t hardcode anything in the code but use the specific environment files to handle specific sinks and settings -per environment-).

[bruno-garcia]

The issue here is that we’re using 2 separate integrations. Both can actually initialize the SDK but you only want (need) the SDK initialized once.

If you were using only Serilog, outside an ASP.NET Core app, you could define everything in the Serilog config. But if you want to capture request data, capture exceptions in the middleware pipeline, capture errors handled by the error page, and all the other features. then you need Sentry.AspNetCore.

The config blocks Sentry and Serilog are separate because they rely on the ASP.NET Core configuration system. and the packages don’t depend on each other. The way they can ‘share state’ is because both of them depend on Sentry package which has AsyncLocal and the Sentry.AspNetCore pushes a scope for each web request. So now your _logger.LogX entries can be kept per-request and sent as breadcrumbs for example, or include request data.

So it’s not like you are configuring the Sentry Serilog Sink outside the Serilog config. You are configuring the Sentry Serilog sink just right. All it’s specific to it are those two logging levels. You are configuring “Sentry” via the root Sentry node in the configuration file which can live without Serilog. Still captures unhandled exceptions, including request data. In fact, if you didn’t have Serilog, it would capture automatically the log messages as breadcrumbs and/or errors because it integrates with Microsoft.Extensions.Logging out of the box.

Wrt configuring via Serilog: SentrySerilogOptions also derives from SentryOptions so it does have everything to init Sentry:

https://github.com/getsentry/sentry-dotnet/blob/46bf5548d347ad1e206aefa3ea91cc46ab02004f/src/Sentry.Serilog/SentrySerilogOptions.cs#L11

In this example we have only Serilog, without any other integration. Here we initialize it all via the Sink:

https://github.com/getsentry/sentry-dotnet/blob/46bf5548d347ad1e206aefa3ea91cc46ab02004f/samples/Sentry.Samples.Serilog/Program.cs#L16-L25

I understand it’s not ideal that the ASP.NET Core and Serilog configuration for Sentry are in different parts of the configuration system but I hope it’s at least now clear why it is this way.

[PureKrome]

Okay. wow. What an awesome and helpful reply @bruno-garcia !

I had to read it a few times, double check the links to grok things … but yep. Totally get it.

I’ve also got a test webapp (file -> new -> aspnet core 2.2 api app) to test this out and it’s more or less working. Well, I can get it working 100% following what you’ve done, but I was hoping for something slightly different. As such, i’m not sure if this should be a different issue or not.

In your example, you’re configuring the Sentry sink via configuration. This is awesome and something that I always do because it means I can then define any sink configuration via environmental variables if required and it can easily work.

When I’ve looked at your configuration, it’s the following:

      {
        "Name": "Sentry",
        "Args": {
          "MinimumBreadcrumbLevel": "Debug",
          "MinimumEventLevel": "Warning"
        }
      }

This makes sense … except … I’ve always thought that a sink configuration should include all the options possible to setup/initialize the sink. As such, this has no argument for the Dsn ? I would have thought that I could define most of the common setup properties here, like MaxRequestBodySize or AttachStackTrace etc. I can see that there’s already 2x properties defined: MinBreadcrumbs and MinEventLvl.

If I try the following, nothing is logged sentry:

           {
                "Name": "Sentry",
                "Args": {
                    "Dsn": "https://<snipped>"
                }
            }

but … if i add the following in, it works now:

    "Sentry": {
        "Dsn": "https://<snipped>"
    },

It feels disjointed having to split these two out. I feel like … if i’m creating the sink via WriteTo (which is what that is there for) I should be able to define most initialization properties there.

So … a summary based on your awesome post:

• ✅ I can log errors to Sentry following your steps!
• ❌ I feel like the configuration of Sentry-via-Serilog should be handled via the WriteTo.

I hope this make sense and interest you …