Serilog.Blazor.Postgres 1.0.0

This is a collection of Blazor components to improve your Serilog experience, currently targeting SQL Server and Blazor Server. NuGet packages:

• Serilog.Blazor.SqlServer
• Serilog.Blazor.RCL
• PostgreSQL support coming soon

Components

<details> <summary>LevelToggle</summary>

Use this to change log levels at runtime in your app for whatever namespaces/source contexts you define. This is handy when you need to temporarily increase log detail in a specific area to troubleshoot a production issue.

Source: LevelToggle

Example: SampleApp

</details>

<details> <summary>SerilogGrid</summary>

Scrolling grid of log entries.

Expands to show exception detail and properties.

Source: SerilogGrid

Example: SampleApp

</details>

<details> <summary>SourceContextFilter</summary>

Zoom out to see total log entries by level and source context.

Source: SourceContextFilter

Example: SampleApp

</details>

<details> <summary>SearchBar</summary>

Search your logs with a variety of shortcuts. Save searches for easy reuse. Supported syntax:

• enclose text in square brackets to search the source context field.
• use a pound sign prefix to search the request Id property.
• use the @ sign prefix to search the log level, e.g. @warn or @err or @info
• use a minus sign prefix followed by number and duration unit, e.g. -15m for within 15 minutes or -1d for one day ago

Source: SearchBar

Example: SampleApp

This has a saved search feature that requires an EF Core DbContext implementing this interface ISerilogSavedSearches.

After implementing this interface on your DbContext, add a migration to add the underlying table to your database.

</details>

Getting Started (SQL Server package)

1. Install the SQL Server and RCL packages listed above.
2. Implement abstract class LogLevels in your app. Example: ApplicationLogLevels
3. In your app startup, create your ApplicationLogLevels instance (or whatever you decide to call it), and use it as the basis of your Serilog configuration. Also be sure to include the SqlServerColumnOptions.Default columnOptions argument. This ensures the SourceContext is captured as a dedicated column in your logs. Example:

var logLevels = new ApplicationLogLevels();

Log.Logger = logLevels
  .GetConfiguration()  
  .WriteTo.MSSqlServer({your connection string}, new MSSqlServerSinkOptions()
  {
    AutoCreateSqlTable = true,
    TableName = "Serilog", // whatever table name you like
    SchemaName = "log", // whatever schema you like
  }, columnOptions: SqlServerColumnOptions.Default) // this is important
  .Enrich.FromLogContext()
  .CreateLogger();

4. If using the SearchBar, add an EF Core IDbContextFactory<T> to your startup. Example.

5. Call extension method AddSerilogUtilities in your app startup. Example:

// to enable search bar saved searches. You might already have a db context being added somewhere, but it needs to be a factory specifically for this library. Lifetime doesn't matter. I use singleton here, but it can be scoped
builder.Services.AddDbContextFactory<ApplicationDbContext>(config => config.UseSqlServer({your connection string}), ServiceLifetime.Singleton);

// adds log level toggle and infrastructure for querying Serilog table. Use your serilog table name and schema. Also, chang ethe TimestampType according to how log entries are timestamped. I'm using Local in the example here
builder.Services.AddSerilogUtilities({your connection string}, logLevels, "log", "Serilog", TimestampType.Local);

Goodies and Extensions

BeginRequestId

Correlating log entries in API or non-SPA web apps can be done with ASP.NET Core's HttpContext.TraceIdentifier property. This is not helpful in Blazor due to how it works with HttpContext. As an alternative, this library provides a generic log correlation extension method BeginRequestId. Use this at the beginning of a method where you want to ensure that all logs written in that scope have a common identifier. Example. This works with LoggingRequestIdProvider to provide an auto-incrementing value when it's called.

@inject LoggingRequestIdProvider RequestId

private void LogThis()
{
  // attach an id to all logging in this method
  Logger.BeginRequestId(RequestId);

  Logger.LogInformation("This is an info log message");

  Logger.LogDebug("This is a debug message");

  // logs from this method call will be correlated with requestId in scope here
  SampleService.DoWork();
}

SerilogCleanup

Implement retention periods for various log levels with the AddSerilogCleanup method, used at startup:

builder.Services.AddSerilogCleanup(new() 
{ 
  ConnectionString = {your connection string}, 
  TableName = "log.Serilog", // your serilog table name
  Debug = 5, // retention period in days
  Information = 20,
  Warning = 20,
  Error = 20
});

Then in your pipeline, call RunSerilogCleanup with a desired interval. This uses Coravel Scheduling, so use its syntax for setting the interval.

var app = builder.Build();

app.Services.RunSerilogCleanup(interval => interval.DailyAt(0, 0)); 

Motivation

When self-hosting Serilog, there's no built-in log view experience. You have to query the serilog table manually and/or build your own UI or query feature. There are products like Seq and Graylog that provide a very polished log search and view exeperience, but have costs of their own. The reason for self-hosting to begin with is to avoid those costs. Furthermore, traditional homegrown log viewers have not provided the kind of insights and capabilities I'm looking for when examining logs. The goal for this project is to build the most capable log view experience I can, addressing longstanding pain points I've come across -- then offer it as a Razor Class Library NuGet package.

With .NET Aspire coming online recently, it has potential to disrupt and improve logging in ASP.NET Core due to its integrated open telemetry support and viewer dashboards. So, I'm very late to this party, and this project may be irrelevant in the short term. But I'm not convinced yet that Aspire's logging/otel does everything I want it to. Furthermore, many apps implement Serilog already, and I think there's a case for meeting apps where they are rather than pushing them to implement Aspire. (I want Aspire to succeed, and am happy to keep tabs on it as it evolves.)