How to use with sinks that depend on ConfigureServices being run first?

[cmeeren]

I'm using this with Serilog.Sinks.ApplicationInsights, but AFAIK there seems to be a conflict:

• When calling .UseSerilog with the configureLogger parameter, configureLogger (which among other things calls Serilog.Sinks.ApplicationInsights' WriteTo.ApplicationInsights) is executed before ASP.NET Core's ConfigureServices.
• ConfigureServices sets up TelemetryConfiguration.Active
• WriteTo.ApplicationInsights needs TelemetryConfiguration.Active to be set up correctly

Is there a way to solve this?

[cmeeren]

cc @aloneguid

[cmeeren]

To be clear, here are the relevant parts of my startup/config code (F#):

type Startup() =
  member __.ConfigureServices(services) =
    services.AddApplicationInsightsTelemetry(fun conf ->
        conf.InstrumentationKey <- "..."
        conf.EnableAdaptiveSampling <- false)


module Program =

  [<EntryPoint>]
  let main args =
    WebHost
      .CreateDefaultBuilder(args)
      .UseSerilog(fun ctx conf -> 
        conf.WriteTo.ApplicationInsights(
          TelemetryConfiguration.Active,
          TelemetryConverter.Traces)
      .UseStartup<Startup>()
      .Build()
      .Run()

What I observe, is that sampling is enabled even though I explicitly disable adaptive sampling (there are plenty Debug Window output saying "Application Insights Telemetry (filtered by SamplingTelemetryProcessor): ...", and I'm missing traces for certain requests in AI). This leads me to the conclusion that the TelemetryConfiguration.Active in WriteTo.ApplicationInsightsTraces() might not be property initialized.

However, I still get traces in AI, so I don't really understand how that could happen without the instrumentation key being configured, which only happens at the same place as adaptive sampling...

(Proper AI config is a nightmare IMO. I've struggled with it on and off for half a year and still haven't gotten it right. /rant)

[cmeeren]

Nevermind. Turns out we had a rogue ApplicationInsights.config in a library far down the dependency hierarchy that was overriding stuff.

[cmeeren]

Actually, as far as the title and original description go, this is still a problem now that TelemetryConfiguration.Active is deprecated (microsoft/ApplicationInsights-dotnet#1152).

In short:

• The Application Insights telemetry config is set up and registered with DI in ConfigureServices (so that it picks up all telemetry initializers and processors that are also registered), and therefore only available after it has ConfigureServices has run
• The telemetry config is needed when configuring Serilog
• UseSerilog is configured before ConfigureServices is called

Related: serilog-contrib/serilog-sinks-applicationinsights#121

How can this be solved?

[JasonTheProgrammer]

If you're using services.Configure<TelemetryConfiguration>(..), as described in this issue regarding deprecation of TelemetryConfiguration.Active, then you can use services.PostConfigure<T>(..), loosely documented here.

So at a basic level, you could have something like this:

.ConfigureServices((context, services) =>
{
    string appInsightsKey = context.Configuration["APPINSIGHTS_INSTRUMENTATIONKEY"];

    services.Configure<TelemetryConfiguration>(tc =>
    {
        tc.InstrumentationKey = appInsightsKey;
    });

    services.PostConfigure<TelemetryConfiguration>(tc =>
    {
        Log.Logger = new LoggerConfiguration()
            .WriteTo.ApplicationInsights(tc, TelemetryConverter.Traces)
            .CreateLogger();
    });
})

[cmeeren]

Thanks! But aren't I then losing out on logging startup exceptions, as well as any custom setup performed by UseSerilog? Including this ConfigureServices stuff:

serilog-aspnetcore/src/Serilog.AspNetCore/SerilogWebHostBuilderExtensions.cs

Lines 139 to 158 in e6e14e6

	static void ConfigureServices(IServiceCollection collection, ILogger logger)
	{
	if (collection == null) throw new ArgumentNullException(nameof(collection));
	if (logger != null)
	{
	// This won't (and shouldn't) take ownership of the logger.
	collection.AddSingleton(logger);
	}
	// Registered to provide two services...
	var diagnosticContext = new DiagnosticContext(logger);
	// Consumed by e.g. middleware
	collection.AddSingleton(diagnosticContext);
	// Consumed by user code
	collection.AddSingleton<IDiagnosticContext>(diagnosticContext);
	}
	}

Case in point: If I call UseSerilog() (without args), and then set Log.Logger in ConfigureServices, then I lose e.g. the Microsoft start/end request messages. I can solve this by adding services.AddSingleton<ILogger>(Log.Logger) after setting Log.Logger, but issues such as this indicates to me that there might be more I may be missing when replacing Log.Logger after calling UseSerilog.

Also, it seems that using services.Configure<TelemetryConfiguration> makes you lose out on a lot of the default config you get with AddApplicationInsightsTelemetry, so I'm really hesitant to use anything but that method.

[cmeeren]

After checking library sources and experimenting for many hours today, here is a workaround I have arrived at which seems to work. Let me know if I'm shooting myself in the foot.

In doing this I have sacrificed logging early startup errors (in main or Startup.ConfigureServices up to and including where I configure the logger), but I am successfully logging "late" startup errors (e.g. in the Startup.Configure method) to Application Insights, and everything else seems to work as normal after (very) cursory testing.

Program.fs

[<EntryPoint>]
let main args =
  WebHost
    .CreateDefaultBuilder(args)
    .CaptureStartupErrors(true)
    .UseSerilog(dispose = true)
    .UseStartup<Startup>()
    .Build()
    .Run()
  0

Startup.fs

type Startup() =

  member __.ConfigureServices(services: IServiceCollection) : unit =
    services.AddApplicationInsightsTelemetry() |> ignore
    let sp = services.BuildServiceProvider()
    let telemetryConfig = sp.GetRequiredService<TelemetryConfiguration>()

    Log.Logger <-
      LoggerConfiguration()
        .WriteTo.ApplicationInsights(telemetryConfig, TelemetryConverter.Traces)
        .CreateLogger()

    services.AddSingleton<ILogger>(Log.Logger) |> ignore

[mikegoatly]

I can see how that would work - it feels very clunky though; building the service provider to configure something for the next time the service provider is built :)

I've got a feeling that calling IServiceCollection.BuildServiceProvider multiple times isn't great (the framework will call it for you once ConfigureServices exits unless you return a pre-built one) I can't remember where I read it - I'll do a bit of digging.

Edit: I suspect it'll be something to do with multiple singleton instance construction in addition to it being extra work at start-up time.

[mikegoatly]

Could you use a lambda ILogger registration instead? I'm unsure of the F# syntax, but in C# it would be:

services.AddSingleton<ILogger>(
    serviceProvider =>
    {
        Log.Logger = new LoggerConfiguration().WriteTo.ApplicationInsights(
                serviceProvider.GetRequiredService<TelemetryConfiguration>(),
                TelemetryConverter.Traces)
            .CreateLogger();

        return Log.Logger;
    });

[sungam3r]

Maybe related to #130

[mikegoatly]

@sungam3r Interesting - so I think that might make something like this possible? (untested)

WebHost.CreateDefaultBuilder(args)
                .UseSerilog((builder, hostingContext, loggerConfiguration) =>
                {
                    var config = loggerConfiguration
                        .ReadFrom.Configuration(hostingContext.Configuration)
                        .Enrich.FromLogContext();

                    builder.ConfigureServices(services => services.AddSingleton(
                        serviceProvider => 
                        {
                            cfg.WriteTo.ApplicationInsights(
                                serviceProvider.GetRequiredService<TelemetryConfiguration>(),
                                TelemetryConverter.Traces);
                            return config;
                        }));
                })
                .UseStartup<Startup>();