Logging is one of those things every application needs, yet most teams treat it like an afterthought. They install a package, copy a config block from some sample, and hope for the best. Then production breaks, logs are missing, and suddenly everyone cares.

In the last post, I covered how to log well — the philosophy, the structure, the mindset.
This post is the natural continuation: how to wire logging into a .NET application in a way that is minimal, deterministic, and production‑ready.

The Minimal Setup: Logging in Program.cs

Let’s start with the smallest, setup you can drop into a MVC based .NET app.

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddControllersWithViews();

builder.Services.AddApplicationInsightsTelemetry();

// Basic logging (console + debug) setup
builder.Logging.ClearProviders(); 
builder.Logging.AddConsole(); 
builder.Logging.AddDebug();
builder.Logging.AddApplicationInsights();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Home/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseRouting();

app.UseAuthorization();

app.MapStaticAssets();

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}")
    .WithStaticAssets();


app.Run();

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddControllersWithViews();

builder.Services.AddApplicationInsightsTelemetry();

// Basic logging (console + debug) setup
builder.Logging.ClearProviders(); 
builder.Logging.AddConsole(); 
builder.Logging.AddDebug();
builder.Logging.AddApplicationInsights();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Home/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseRouting();

app.UseAuthorization();

app.MapStaticAssets();

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}")
    .WithStaticAssets();


app.Run();

you may need to add the application insights package for line 6 above to work which you can do that from the following

dotnet add package Microsoft.ApplicationInsights.AspNetCore

dotnet add package Microsoft.ApplicationInsights.AspNetCore

Environment overrides

A production‑ready logging setup isn’t complete until it behaves correctly and predictable across environments. Two details matter most: activating Application Insights logging explicitly, and understanding how .NET resolves configuration across multiple appsettings files.

Explicitly Enabling Application Insights Logging

One subtle but important requirement when using Application Insights is that it does not automatically inherit the global Logging:LogLevel settings. The built‑in providers like console will respect the global log levels, but the Application Insights provider stays inactive unless you explicitly configure it.

To ensure application insights participates in the logging pipeline, add a dedicated section in your appsettings.json file:

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

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

This is what “activates” the Application Insights logger. Without it, traces may not appear in Application Insights even though everything else looks correct. With it, the provider becomes a first‑class participant in the logging pipeline.

Using Environment‑Specific Files

.NET’s configuration system is hierarchical and layered. The order matters, and later files override earlier ones. The typical sequence is:

1. appsettings.json – defines the baseline
2. appsettings.{Environment}.json – overrides only the keys that are redefined for environment specific settings

In context to the application insights and logging, the config setup might look like

appsettings.json

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

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

appsettings.Development.json

{
  "Logging": {
    "LogLevel": {
      "Default": "Debug"
    }
  }
}

{
  "Logging": {
    "LogLevel": {
      "Default": "Debug"
    }
  }
}

appsettings.Production.json

{
  "Logging": {
    "ApplicationInsights": {
      "LogLevel": {
        "Default": "Information"
      }
    }
  }
}

{
  "Logging": {
    "ApplicationInsights": {
      "LogLevel": {
        "Default": "Information"
      }
    }
  }
}

This structure keeps your configuration intentional:

• Development gets Debug verbosity
• Production activates Application Insights and keeps noise controlled
• The base file defines the shared defaults
• No duplication, no surprises, no accidental overrides