Obviously when you’re running an ASP.NET core application in Azure, we’re going to want the ability to capture logs to Azure. This usually means logging to Application Insights.

Adding Logging

Let’s start out by just looking at what we need to do to enable logging from ASP.NET core.

Logging is included by default in the way of the ILogger interface (ILogger<T>), hence we can inject into our code like this (this example uses minimal API)

app.MapGet("/test", (ILogger<Program> logger) =>
{
    logger.LogCritical("Critical Log");
    logger.LogDebug("Debug Log");
    logger.LogError("Error Log");
    logger.LogInformation("Information Log");
    logger.LogTrace("Trace Log");
    logger.LogWarning("Warning Log");
})
.WithName("Test")
.WithOpenApi();

To enable/filter logging we have something like the following within the appsettings.json file

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
}

The LogLevel, Default section sets the minimum logging level for all categories. So for example a Default of Information means only logging of Information level and above (i.e. Warning, Error and Critical) are captured.

The Microsoft.AspNetCore is a category specific logging in that it logs Microsoft.AspNetCore namespace logging using the supplied log level. Because we can configure by namespace we can also use categories such as Microsoft, System, Microsoft.Hosting.Lifetime. We can also do the same with our code, i.e. MyApp.Controllers, so this allows us to really start to tailor different sections of our application an what gets captured in the logs.

Logging Levels

There various logging levels are as follows

• LogLevel.Trace: The most detailed level, use for debugging and tracing (useful for entering/existing methods and logging variables).
• LogLevel.Debug: Detailed but less so than Trace (useful for debugging and workflow logging).
• LogLevel.Information: Information messages at a higher level than the previous two levels (useful for logging steps of processing code).
• LogLevel.Warning: Indicates potentially problems that do not warrant error level logging.
• LogLevel.Error: Use for logging errors and exceptions and other failures.
• LogLevel.Critical: Critical issues that may cause an application to fail, such as those that might crash your application. Could also include things like missing connection strings etc.
• LogLevel.None: Essentially disables logging

Application Insights

Once you’ve created an Azure resource group and/or Application Insights service, you’ll be able to copy the connection string to connect to Application Insights from your application.

Before we can use Application Insights in our application we’ll need to

• Add the nuget package Microsoft.ApplicationInsights.AspNetCore to our project
• Add the ApplicationInsights section to the appsettings.json file, something this

  "ApplicationInsights": {
    "InstrumentationKey": "InstrumentationKey=xxxxxx",
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning"
    }
  },
  

  We can obviously set the InstrumentKey in code if preferred, but the LogLevel is specific to what is captured within Application Insights

• Add the following to the Program.cs file below CreateBuilder

  var configuration = builder.Configuration;
  
  builder.Services.AddApplicationInsightsTelemetry(options =>
  {
      options.ConnectionString = configuration["ApplicationInsights:InstrumentationKey"];
  });
  

Logging Providers in code

We can also add logging via code, so for example after the CreateBuilder line in Program.cs we might have

builder.Logging.ClearProviders();
builder.Logging.AddConsole();
builder.Logging.AddDebug(); 

In the above we start by clearing all currently logging providers, the we add a provider for logging to console and debug. The appsettings.json log levels are still relevant to which logs we wish to capture.