A logging provider receives log events recorded through ILogger and displays or stores them. The application can use more than one provider, so the same logging call can reach different destinations. In an ASP.NET Core API, ILogger<T> is commonly supplied to a controller through dependency injection; T supplies the log category. section 7.2.4 section 7.2
Console and Debug make logs easy to see while developing, but large collections of unstructured messages can be hard to search. A structured logging provider writes records to storage that supports queries—for example, filtering by level, event ID, or time. Serilog can provide this capability while the API keeps its existing Microsoft.Extensions.Logging calls. section 7.2.4 section 7.3.1 section 7.4.1
To add structured SQL Server logging to the board-game API:
- Keep the existing ILogger calls in controllers and the error endpoint; there is no need to replace them with Serilog’s native API. section 7.2 section 7.2.6 section 7.4.1
- Configure Serilog in Program.cs with UseSerilog and an MSSqlServer sink. Supply a connection string, name the LogEvents table, and enable automatic table creation. section 7.4.3
- Set writeToProviders to true if Console, Debug, or other registered Microsoft logging providers should continue receiving events alongside the SQL Server sink. section 7.4.3
What the stored record contains
The configured SQL Server sink creates a LogEvents table with fields including Message, MessageTemplate, Level, TimeStamp, Exception, and Properties. Check that table after the API writes an event to confirm that a record was stored, not merely printed to the console. section 7.4.3
Using the existing application database keeps logs and board-game data together; a separate database or external repository provides more separation. Serilog sinks select destinations, while enrichers can add context such as a process ID or machine name to events. section 7.3.2 section 7.4.1
