Serilog logging for ASP.NET Core. This package routes ASP.NET Core log messages through Serilog, so you can get information about ASP.NET's internal operations written to the same Serilog sinks as your application events.
With Serilog.AspNetCore installed and configured, you can write log messages directly through Serilog or any ILogger interface injected by ASP.NET. All loggers will use the same underlying implementation, levels, and destinations.
First, install the Serilog.AspNetCore NuGet package into your app.
dotnet add package Serilog.AspNetCoreNext, in your application's Program.cs file, configure Serilog first. A try/catch block will ensure any configuration issues are appropriately logged:
using Serilog;
public class Program
{
public static int Main(string[] args)
{
Log.Logger = new LoggerConfiguration()
.MinimumLevel.Debug()
.MinimumLevel.Override("Microsoft", LogEventLevel.Information)
.Enrich.FromLogContext()
.WriteTo.Console()
.CreateLogger();
try
{
Log.Information("Starting web host");
CreateHostBuilder(args).Build().Run();
return 0;
}
catch (Exception ex)
{
Log.Fatal(ex, "Host terminated unexpectedly");
return 1;
}
finally
{
Log.CloseAndFlush();
}
}Then, add UseSerilog() to the Generic Host in CreateHostBuilder().
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.UseSerilog() // <-- Add this line
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup<Startup>();
});
}Finally, clean up by removing the remaining configuration for the default logger:
- Remove the
"Logging"section from appsettings.json files (this can be replaced with Serilog configuration as shown in the EarlyInitializationSample project, if required) - Remove
UseApplicationInsights()(this can be replaced with the Serilog AI sink, if required)
That's it! With the level bumped up a little you will see log output resembling:
[22:14:44.646 DBG] RouteCollection.RouteAsync
Routes:
Microsoft.AspNet.Mvc.Routing.AttributeRoute
{controller=Home}/{action=Index}/{id?}
Handled? True
[22:14:44.647 DBG] RouterMiddleware.Invoke
Handled? True
[22:14:45.706 DBG] /lib/jquery/jquery.js not modified
[22:14:45.706 DBG] /css/site.css not modified
[22:14:45.741 DBG] Handled. Status code: 304 File: /css/site.css
Tip: to see Serilog output in the Visual Studio output window when running under IIS, either select ASP.NET Core Web Server from the Show output from drop-down list, or replace WriteTo.Console() in the logger configuration with WriteTo.Debug().
A more complete example, showing appsettings.json configuration, can be found in the sample project here.
The package includes middleware for smarter HTTP request logging. The default request logging implemented by ASP.NET Core is noisy, with multiple events emitted per request. The included middleware condenses these into a single event that carries method, path, status code, and timing information.
As text, this has a format like:
[16:05:54 INF] HTTP GET / responded 200 in 227.3253 ms
Or as JSON:
{
"@t": "2019-06-26T06:05:54.6881162Z",
"@mt": "HTTP {RequestMethod} {RequestPath} responded {StatusCode} in {Elapsed:0.0000} ms",
"@r": ["224.5185"],
"RequestMethod": "GET",
"RequestPath": "/",
"StatusCode": 200,
"Elapsed": 224.5185,
"RequestId": "0HLNPVG1HI42T:00000001",
"CorrelationId": null,
"ConnectionId": "0HLNPVG1HI42T"
}To enable the middleware, first change the minimum level for Microsoft.AspNetCore to Warning in your logger configuration or appsettings.json file:
.MinimumLevel.Override("Microsoft.AspNetCore", LogEventLevel.Warning)Then, in your application's Startup.cs, add the middleware with UseSerilogRequestLogging():
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
app.UseExceptionHandler("/Home/Error");
}
app.UseSerilogRequestLogging(); // <-- Add this line
// Other app configurationIt's important that the UseSerilogRequestLogging() call appears before handlers such as MVC. The middleware will not time or log components that appear before it in the pipeline. (This can be utilized to exclude noisy handlers from logging, such as UseStaticFiles(), by placing UseSerilogRequestLogging() after them.)
During request processing, additional properties can be attached to the completion event using IDiagnosticContext.Set():
public class HomeController : Controller
{
readonly IDiagnosticContext _diagnosticContext;
public HomeController(IDiagnosticContext diagnosticContext)
{
_diagnosticContext = diagnosticContext ??
throw new ArgumentNullException(nameof(diagnosticContext));
}
public IActionResult Index()
{
// The request completion event will carry this property
_diagnosticContext.Set("CatalogLoadTime", 1423);
return View();
}This pattern has the advantage of reducing the number of log events that need to be constructed, transmitted, and stored per HTTP request. Having many properties on the same event can also make correlation of request details and other data easier.
The following request information will be added as properties by default:
RequestMethodRequestPathStatusCodeElapsed
You can modify the message template used for request completion events, add additional properties, or change the event level, using the options callback on UseSerilogRequestLogging():
app.UseSerilogRequestLogging(options =>
{
// Customize the message template
options.MessageTemplate = "Handled {RequestPath}";
// Emit debug-level events instead of the defaults
options.GetLevel = (httpContext, elapsed, ex) => LogEventLevel.Debug;
// Attach additional properties to the request completion event
options.EnrichDiagnosticContext = (diagnosticContext, httpContext) =>
{
diagnosticContext.Set("RequestHost", httpContext.Request.Host.Value);
diagnosticContext.Set("RequestScheme", httpContext.Request.Scheme);
};
});You can alternatively configure Serilog inline, in BuildWebHost(), using a delegate as shown below:
.UseSerilog((hostingContext, services, loggerConfiguration) => loggerConfiguration
.ReadFrom.Configuration(hostingContext.Configuration)
.Enrich.FromLogContext()
.WriteTo.Console())This has the advantage of making a service provider and the hostingContext's Configuration object available for configuration of the logger, but at the expense of losing Exceptions raised earlier in program startup.
If this method is used, Log.Logger is assigned implicitly, and closed when the app is shut down.
A complete example, showing this approach, can be found in the InlineIntializationSample project.
Serilog sends events to outputs called sinks, that implement Serilog's ILogEventSink interface, and are added to the logging pipeline using WriteTo. Microsoft.Extensions.Logging has a similar concept called providers, and these implement ILoggerProvider. Providers are what the default logging configuration creates under the hood through methods like AddConsole().
By default, Serilog ignores providers, since there are usually equivalent Serilog sinks available, and these work more efficiently with Serilog's pipeline. If provider support is needed, it can be optionally enabled.
Using the recommended configuration:
In the recommended configuration (in which startup exceptions are caught and logged), first create a LoggerProviderCollection in a static field in Program.cs:
// using Serilog.Extensions.Logging;
static readonly LoggerProviderCollection Providers = new LoggerProviderCollection();Next, add WriteTo.Providers() to the logger configuration:
.WriteTo.Providers(Providers)Finally, pass the provider collection into UseSerilog():
.UseSerilog(providers: Providers)Providers registered in Startup.cs with AddLogging() will then receive events from Serilog.
Using inline initialization:
If inline initialization is used, providers can be enabled by adding writeToProviders: true to the UseSerilog() method call:
.UseSerilog(
(hostingContext, loggerConfiguration) => /* snip! */,
writeToProviders: true)The Console(), Debug(), and File() sinks all support JSON-formatted output natively, via the included Serilog.Formatting.Compact package.
To write newline-delimited JSON, pass a CompactJsonFormatter or RenderedCompactJsonFormatter to the sink configuration method:
.WriteTo.Console(new RenderedCompactJsonFormatter())The Azure Diagnostic Log Stream ships events from any files in the D:\home\LogFiles\ folder. To enable this for your app, add a file sink to your LoggerConfiguration, taking care to set the shared and flushToDiskInterval parameters:
public static int Main(string[] args)
{
Log.Logger = new LoggerConfiguration()
.MinimumLevel.Debug()
.MinimumLevel.Override("Microsoft", LogEventLevel.Information)
.Enrich.FromLogContext()
.WriteTo.Console()
// Add this line:
.WriteTo.File(
@"D:\home\LogFiles\Application\myapp.txt",
fileSizeLimitBytes: 1_000_000,
rollOnFileSizeLimit: true,
shared: true,
flushToDiskInterval: TimeSpan.FromSeconds(1))
.CreateLogger();If you want to add extra properties to all logevents in a specific part of your code, you can add them to the ILogger<T> in Microsoft.Extensions.Logging with the following code. For this code to work, make sure you have added the .Enrich.FromLogContext() to the .UseSerilog(...) statement, as specified in the samples above.
// Microsoft.Extensions.Logging ILogger<T>
// Yes, it's required to use a dictionary. See https://nblumhardt.com/2016/11/ilogger-beginscope/
using (logger.BeginScope(new Dictionary<string, object>
{
["UserId"] = "svrooij",
["OperationType"] = "update",
}))
{
// UserId and OperationType are set for all logging events in these brackets
}The code above results in the same outcome as if you would push properties in the ILogger in Serilog.
// Serilog ILogger
using (logger.PushProperty("UserId", "svrooij"))
using (logger.PushProperty("OperationType", "update"))
{
// UserId and OperationType are set for all logging events in these brackets
}