AspNetCore - Logging and parameters

[dazinator]

I am using the popular serilog logging library which is a structured logger.

At the moment, when an exception occurs in a job, the message being logged looks like a simple formatted string e.g: Failed to process the job '93364': an exception occurred.

This correlates with a log statement that looks as follows:

 _logger.LogError("Failed to process the job '93364': an exception occurred.");

Because this logs a simple string which is always unique per log event, it means it doesn't work well with structured logging providers such as serilog. Please can it be changed to log similar to the following:

 _logger.LogError("Failed to process the job '{jobId}': an exception occurred.", jobId);

This allows the hashcode of the message template to remain constant each time an event is logged (which becomes important if using serilog in conjunction with something like seq) and allows any structured log provider to capture the value of the job id as a parameter which is useful when you want to filter or query those logs later by particular job ids.

[jimmcslim]

I would also add that it would be good if the SerilogLogProvider could be enhanced to specify additional properties that are used by the Serilog logger instance used by Hangfire; e.g. I would like to add a Component = 'Hangfire' key-value pair to all messages being logged by Hangfire so I can easily distinguish them from other components in my application.

[jimmcslim]

Another thing to add... NLog also supports structured logging. Also the LibLog logging API wrapper is structured logging aware.

[Sebbl22]

+1 for this feature
It is important for us to determine, if a log message is reoccurring or 'unique'. Since hangfire messages are always unique for structured loggers like Serilog, we are unable to do that.

[parijsy]

I would love to have this feature as well, because in its current state the logging is creating a lot of event types in seq and the log entries are difficult to search through.
As mentioned by jimmcslim LibLog is structured logging aware, however the version used by HangFire (1.4 or 1.5) still has shortcomings.
The main issue with the current version is that parameters cannot be used simultaneously with exceptions, also the parameters cannot be named because a simple string.Format is used.
Starting from LibLog 3.0.0 these shortcomings are solved.

As a test I've done a quick and dirty upgrade of LibLog to version 3.0.0 and updated a few log entries with success.
When rewriting the log entries to use parameters I personally prefered to add a prefix to the parameter name so I would know it's from HangFire, I was playing around with the prefix "Hf" and "Hf_".

[stijnherreman]

I don't know how feasible it is to remove LibLog altogether, but for the record: LibLog is deprecated and the author recommends migrating to Microsoft.Extensions.Logging. See also: #1584