Consider not initialising the Sdk from logging integrations

[jamescrosswell]

Description

This and this and this are just three examples in the last two weeks of many many conversations we've had about this issue over the years. It's very confusing to SDK users and even trips us up as maintainers on occasion.

Currently you can initialise Sentry:

1. Via integrations like our Maui or Asp.Net Core integration that support a certain app type/framework
2. Via the static SentrySdk.Init
3. Via one of our logging integrations

The trouble is that the logging integrations are frequently used in conjunction with one of the first two types and then you have to tell the logging integration: Yes do send logs to Sentry, but no do not initialise the Sentry SDK (it's already been initialised).

Initialisation via the logging integrations was added so that if someone is only using the logging integration (e.g. in a Console app) they don't need to call SentrySdk.Init... it saves them a method call at startup.

Given the amount of confusion this causes, I think we should consider changing this so the logging integrations only configure the sink or whatever and the SDK always has to be initialised separately via 1 or 2.

[linear-code]

NET-687

[Mike-E-angelo]

Thank you for creating this. I may be biased due to my previous use of Seq before Sentry, but we only use appSettings.json to configure our Serilog + all logging accordingly. Because of this, the expectation in an ASP.NET Core application is that no further calls should be necessary to configure logging. We cannot pass in a dsn into an overload because it is supplied in the appSettings.json (based on environment) and it is unclear how to load this and pass it in as a value at application start time.

What is also confusing is there appears to be a configuration that is applied based on whether the dsn is assigned:

sentrySerilogOptions.InitializeSdk = dsn is not null; // Inferred from the Sentry overload that is used

So the SDK is initialized at this point? I guess I will have to put a breakpoint in there to find out for sure. Not exactly a smooth installation experience.

[jamescrosswell]

we only use appSettings.json to configure our Serilog + all logging accordingly. Because of this, the expectation in an ASP.NET Core application is that no further calls should be necessary to configure logging.

What I'm. suggesting here is that you would configure most of the Sentry settings in a Sentry block in appsettings.json (like this). You could do that whether you're using Serilog or not (unrelated to what you use for logging or how you choose to configure that).

Separately, you might have a much smaller block in your appsettings.json file that configures how logs from your logging framework should be captured by sentry. Under the hood, that would be configuring a custom Sentry sink or whatever for your logging framework of choice.

So this proposal wouldn't stop you from using your appsettings.json file for configuration bindings. It just means that you'd configure the Sentry SDK in a consistent place, regardless of whether you choose to use one of the logging integrations (or which logging framework you use).

[Mike-E-angelo]

Thank you very much for your patience in explaining this to me @jamescrosswell it is appreciated. Part of the confusion here is that your own samples throw exceptions as currently configured. In particular, these lines throw an error:

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

Lines 21 to 25 in 7111fb5

	.WriteTo.Sentry(s =>
	{
	s.MinimumBreadcrumbLevel = LogEventLevel.Debug;
	s.MinimumEventLevel = LogEventLevel.Error;
	}));

I have to change it to this (the recommended overload as you suggest) for it to work:

.WriteTo.Sentry(minimumBreadcrumbLevel: LogEventLevel.Debug, minimumEventLevel: LogEventLevel.Error))