Question: is there much difference/lacking features of the Serilog.Sentry library (vs main Sentry SDK)?

[PureKrome]

G'Day 👋🏻 !

With the Sentry.Serilog library, is there much features missing .. versus using the main Sentry library?

Context: I prefer to pass ILogger<T> all around my application. In my ConfigureServices, I would prefer to just setup Serilog and then log whatever to wherever, via sinks, like Sentry.Serilog.

So if I get an error, I would then log that to Sentry.

Is it safe to assume that the data which is logged to sentry via the Serilog sink is pretty much feature rich as manually using the Serilog library? Like, rich exception information, etc?

Or in other words, if I use the Sentry.Serilog library, I would be missing out of the following pieces of data:

• <something>
• <another thing>
• etc.

[bruno-garcia]

For the main Sentry package, you're not missing anything.

Except that you can use the Sentry API to add more data to the event. Like Contexts or tags which get indexed.

The protocol has well defined stuff: https://develop.sentry.dev/sdk/event-payloads/
C# API Docs: https://getsentry.github.io/sentry-dotnet/api/Sentry.Protocol.html

But the integrations such as UnhandledException and UnobservedTaskException are hooked up automatically so even if you're using Sentry.Serilog, such errors would be captured.

For more context, check out the Sentry Serilog Sink, and you'll see what we do use. And if you check out the API docs, and the Sentry Docs you'll what possible through the SDK itself (not limited by a logging integration).

If you're on a ASP.NET Core app, and don't install the Sentry.AspNetCore you'll be missing:

• Request information like headers
• User agent is used by Sentry to show browser, OS info
• Errors handled by the error page
• Exceptions thrown in the middleware pipeline
• User authenticated in ASP.NET Core is
• .. other that I can't think of right now

Similar data for ASP.NET classic (which btw, is moving to a Sentry.AspNet dedicated package on Sentry SDK 3.0.0.

[PureKrome]

Thanks @bruno-garcia for the help/reply.

So if i understand you right ...

• Sentry nuget and Sentry.Serilog nuget offer the same functionality. Of course, the Serilog one is just a wrapper.

Quote from docs:

This package extends Sentry main SDK. That means that besides the logging related features, through this package you'll also get access to all API and features available in the main Sentry SDK.

kewl!

Except that you can use the Sentry API to add more data to the event.

Does this mean that if you just use the Sentry nuget, you can do more stuff (add a context and tags) while the Serilog.Sentry nuget hasn't exposed this?

If you're on a ASP.NET Core app, and don't install the Sentry.AspNetCore you'll be missing:

So I like using Serilog because it has the concept of sinks. So (for example) I can get logs going to

• console
• seq
• sentry

and only have one MS ILogger passed around to my code and various reusable nuget libraries that are logging agnostic.

So this means I would be missing out on these lovely extra's, for an ASP.NET Core app, because I would only be installed Serilog.Sentry. Is there any reason why there isn't a Serilog.Sentry.AspNetCore nuget?

[bruno-garcia]

Except that you can use the Sentry API to add more data to the event.

Does this mean that if you just use the Sentry nuget, you can do more stuff (add a context and tags) while the Serilog.Sentry nuget hasn't exposed this?

Installing Sentry.Serilog brings in also Sentry so you're free to using Sentry; and call directly the Sentry SDK API like SentrySdk.ConfigureScope(s => s.SetTag("key, "value"));.

If you're on a ASP.NET Core app, and don't install the Sentry.AspNetCore you'll be missing:

So I like using Serilog because it has the concept of sinks. So (for example) I can get logs going to

• console
• seq
• sentry

and only have one MS ILogger passed around to my code and various reusable nuget libraries that are logging agnostic.

Right, this is how I used Sentry on NuGet Trends too.

So this means I would be missing out on these lovely extra's, for an ASP.NET Core app, because I would only be installed Serilog.Sentry. Is there any reason why there isn't a Serilog.Sentry.AspNetCore nuget?

You can install both Sentry.Serilog and Sentry.AspNetCore. I did that on NuGet Trends:

https://github.com/dotnet/nuget-trends/blob/d114dc6bb76d729411b6cce45e135ed809257aed/src/NuGetTrends.Api/NuGetTrends.Api.csproj#L18-L19

Here you can see how I initialize Serilog before ASP.NET Core so even if the service fails to start, I'll get an event in Sentry:

https://github.com/dotnet/nuget-trends/blob/4209af5347ad91d1171479df53f624caa634bb79/src/NuGetTrends.Api/Program.cs#L14-L67

Adding both packages also make sure you can can get Sentry through dependency injection.

There's an example of ASP.NET Core and Serilog in this repo, that shows resolving Sentry from the DI container:

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

Lines 59 to 69 in ba8e98e

	var hub = context.RequestServices.GetService<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!");

In a real world app you're likely taking the dependency via constructor injection, but the sample exists to give you an idea of what's possible, in a simple way/single file. There's more info about ISentryClient and IHub on the docs but basically adding data to the scope via IHub is the same as adding via SentrySdk static class, but one will help make your cost testable since you can easily mock IHub.

[PureKrome]

Installing Sentry.Serilog brings in also Sentry so you're free to using Sentry; and call directly the Sentry SDK API like SentrySdk.ConfigureScope(s => s.SetTag("key, "value"));

Hmm. okay! Nice! That would work for Sentry-specific logging (and for constant data) while .. the other sinks would not get this info, though? (more on this, below).

Is there any reason why this can't be set TAGS or EXTRA via app settings in a serilog key/value section ? Rational, I try and keep as much configuration stuff out of the code and into the appsettings.<xxx>.json files, where appropriate (e.g. constant data, not dynamic data).

which segways now to dynamic data and Logging Scopes :)

does the Serilog.Sentry package offer Logging Scopes using the MS default Logger ? Is this what IHub is?

for example, all our code everywhere will aways use ctor injection of an ILogger<T> and then in our code, use Logging Scopes like this:

(note: I prefer to use key/values with my logging scopes...)

public void SomeMethod()
{
    var scopes = new Dictionary<string, string>
    {
        { nameof(transactionId), transactionId },
        { nameof(orderId), orderId }
    };
    using (_logger.BeginScope(scopes))
    {
        // lots of code here.
    } 

    // those scopes are now NOT part of any logging messages, after this point/line.

There's an example of ASP.NET Core and Serilog in this repo, that shows resolving Sentry from the DI container:

Okay, so in this example provided, it looks like some middleware that retrieves an IHub from DI. Which means ... my code is now very aware that error logging is to Sentry and Sentry only (verus, being logging agnostic). Remember, I prefer to log anything to various sinks (including errors, for example), where Sentry is just one sink in my list.

So in the above example, if the middleware detects that the current request is trying to go to route "/throw", then do I need to create a Sentry-scope (the `IHub) and then the MS logger scopes, to make sure all sinks capture this? Feels awkward, if that's the case.

In summary, as asked above, is an IHub the "sentry way" of doing logging scopes (where tags are indexed and extra's are not) and we can't just leverage the MS Logger 'scopes' instead, keeping our code logging agnostic?

---

Here you can see how I initialize Serilog before ASP.NET Core

Great! this is basically the same code I have in my SimpleHosting nuget library so people don't have to repeat that ceremony every single time they have a new app. 💪🏻 👍🏻

[bruno-garcia]

Installing Sentry.Serilog brings in also Sentry so you're free to using Sentry; and call directly the Sentry SDK API like SentrySdk.ConfigureScope(s => s.SetTag("key, "value"));

Hmm. okay! Nice! That would work for Sentry-specific logging (and for constant data) while .. the other sinks would not get this info, though? (more on this, below).

Yeah if you call SentrySdk.Something that won't go into Serilog sinks.

Is there any reason why this can't be set TAGS or EXTRA via app settings in a serilog key/value section ? Rational, I try and keep as much configuration stuff out of the code and into the appsettings.<xxx>.json files, where appropriate (e.g. constant data, not dynamic data).

The ASP.NET Core integration has that:

sentry-dotnet/samples/Sentry.Samples.AspNetCore5.Mvc/appsettings.json

Lines 22 to 24 in e17703a

	"DefaultTags": {
	"default-key-in-config": "default-value"
	}

The Serilog integration itself doesn't have DefaultTags. We could lift this to SentryOptions though, it's common enough. Then you'd be able to bind from your config into the Serilog options.
Do you want to open a PR?

which segways now to dynamic data and Logging Scopes :)

does the Serilog.Sentry package offer Logging Scopes using the MS default Logger ? Is this what IHub is?

Hub contains the scope stack + the Sentry client. So it has PushScope and PopScope.
The logging integration (MS Logger) does map to it.

for example, all our code everywhere will aways use ctor injection of an ILogger<T> and then in our code, use Logging Scopes like this:

(note: I prefer to use key/values with my logging scopes...)

public void SomeMethod()
{
    var scopes = new Dictionary<string, string>
    {
        { nameof(transactionId), transactionId },
        { nameof(orderId), orderId }
    };
    using (_logger.BeginScope(scopes))
    {
        // lots of code here.
    } 

    // those scopes are now NOT part of any logging messages, after this point/line.

On the latest version of the SDK it should be: 2.1.8. Please let me know if not, it would be a bug.

There's an example of ASP.NET Core and Serilog in this repo, that shows resolving Sentry from the DI container:

Okay, so in this example provided, it looks like some middleware that retrieves an IHub from DI. Which means ... my code is now very aware that error logging is to Sentry and Sentry only (verus, being logging agnostic). Remember, I prefer to log anything to various sinks (including errors, for example), where Sentry is just one sink in my list.

So in the above example, if the middleware detects that the current request is trying to go to route "/throw", then do I need to create a Sentry-scope (the `IHub) and then the MS logger scopes, to make sure all sinks capture this? Feels awkward, if that's the case.

I don't really understand what you said. You don't need to create any scope. That's an optional feature to add some data to a potential event (if something is captured within the scope). When Disposed, the data is also removed (except if an ASP.NET Core request is ongoing btw so we keep it all until the end of the request).

The example is just an example. You don't need to get IHub either. It's just to show you how to use the Sentry SDK. If you want to only use ILogger, you can. It's pretty rich in API already with BeginScope<TState> and the Log method.

In summary, as asked above, is an IHub the "sentry way" of doing logging scopes (where tags are indexed and extra's are not) and we can't just leverage the MS Logger 'scopes' instead, keeping our code logging agnostic?

You don't need to use IHub. You can configure how to map the TState to Sentry's scope by overriding: Options.SentryScopeStateProcessor. Can't do that via json config since it's code.

Here's an example:

sentry-dotnet/samples/Sentry.Samples.Console.Customized/Program.cs

Line 112 in 58670f6

o.SentryScopeStateProcessor = new MyCustomerScopeStateProcessor();

ANd:

sentry-dotnet/samples/Sentry.Samples.Console.Customized/Program.cs

Lines 272 to 287 in 58670f6

	private class MyCustomerScopeStateProcessor : ISentryScopeStateProcessor
	{
	private readonly ISentryScopeStateProcessor _fallback = new DefaultSentryScopeStateProcessor();
	public void Apply(IScope scope, object state)
	{
	if (state is SpecialContextObject specialState)
	{
	scope.SetTag("SpecialContextObject", specialState.A + specialState.B);
	}
	else
	{
	_fallback.Apply(scope, state);
	}
	}
	}

Here you can see how I initialize Serilog before ASP.NET Core

Great! this is basically the same code I have in my SimpleHosting nuget library so people don't have to repeat that ceremony every single time they have a new app. 💪🏻 👍🏻

I hope this clarifies things a bit.

[PureKrome]

Phew! There's a lot to grok, so lets see if I understand the replies

• Sentry.AspNetCore has appsettngs.json support for default tags. This is missing from Serilog.Sinks.Sentry. A PR to accept this would be considered.
• MS Logger supports BeginScope and Sentry (2.1.8+) respects this. So if we use MS Logger + BeginScope + Sentry, we should see the scoped data in Sentry.
• Because Sentry respect the MS Logger scopes, by inheritance, the Serilog.Sinks.Sentry nuget library should also handle MS Logger + Scopes.

Does that sounds about right?

[bruno-garcia]

Sentry.AspNetCore has appsettngs.json support for default tags. This is missing from Serilog.Sinks.Sentry. A PR to accept this would be considered.

We could move default tags to SentryOptions so all integrations could leverage.

MS Logger supports BeginScope and Sentry (2.1.8+) respects this. So if we use MS Logger + BeginScope + Sentry, we should see the scoped data in Sentry.

It always had it, but before 2.1.8, on ASP.NET Core (with the scope locked) it didn't keep the values. See #594

Because Sentry respect the MS Logger scopes, by inheritance, the Serilog.Sinks.Sentry nuget library should also handle MS Logger + Scopes.

Serilog does some funny stuff with ASP.NET Core with regards to logging backend. I see the Sink itself adds some Serilog properties stuff as Extra:

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

Line 109 in e17703a

evt.SetExtras(GetLoggingEventProperties(logEvent));

I suggest trying stuff out though.

[PureKrome]

Great - created an issue (in preparation for a PR) to test this stuff out, etc.