ScyberLog is a low-nonsense logging framework designed to meet a set of specific requirements:
Simple configuration
Rolling file logger that supports JSON formatted output
Integration with .NET core logging extensions without excluding parameters which don't appear in the message template.
Support for log scopes
This framework isn't intended to compete with the other big logging frameworks out there in terms of performance and configurability. Instead it aims to fill a gap in the available options by providing something simpler for small projects. If you need something to drop in a pet project that doesn't require you to read a novel of documentation, download a bunch of 3rd party appenders and sinks (each with their own usage docs), and hand roll formatters just to get your logs into a json formatted file, then this the framework for you. And since it only relies on the built in logging interfaces in .NET Core, you can always swap it out without changing your codebase once you outgrow it.
Output
By default, ScyberLog writes log entries to both the console and a file.
A log message like this:
First, use the included extension to add the logger to the logging builder in the host builder; this will be very slightly different depending on your environment.
Worker Service:
IHost host = Host.CreateDefaultBuilder(args)
.ConfigureServices(services =>
{
services.AddHostedService<Worker>();
})
.ConfigureLogging((HostBuilderContext hostingContext, ILoggingBuilder loggingBuilder) =>
{
//Clear out the console provider automatically added by the hosted service
loggingBuilder.ClearProviders();
loggingBuilder.AddScyberLog();
})
.Build();
_logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now, new { ExtraData = "HelloWorld"});
If you log a message like the above in another framework, you'll get a compiler warning about the number of parameters supplied to the logging extention methods. This is because by default, .NET throws away parameters that aren't interpolated into the message when the message is written. ScyberLog takes the stance that this information shouldn't be lost, and behaves differently. If you intend to take advantage of this feature, know that if you later switch to another framework, this information will be lost. Avoid it if you want to preserve the ability to switch logging frameworks in the future without a change in behavior.
Including the following line in your project will remove the compiler warnings.
using System.Diagnostics.CodeAnalysis;
[assembly: SuppressMessage("Usage", "CA2017:Number of parameters supplied in the logging message template do not match the number of named placeholders", Justification = "ScyberLog captures unused parameters")]
Configuration
You can configure the logger by either using adding a ScyberLog node to your appsettings.json file and passing your IConfiguration instance to the AddScyberLog method, by using the optional configuration action parameter in the AddScyberLog extension, or by using the .Configure<ScyberLogConfiguration>() extension on your service collection.
NOTE Ironically, not all properties of the JsonSerializerOptions are serializable from JSON, so if you aren't happy with the defaults you'll need to configure them in code. The default configuration is below; note that as of this writing the built in serializer fails to serialize System.Exception and hence the library has a custom converter.
Scyberlog "supports" datetime based file rolling, mainly by interpolating the date into the filename when writing to the log. The default file name is "Log\\{0:yyyy-MM-dd}.log". The Filename template is a standard format string, with the 0th parameter being the current datetime and the 1st parameter being the logger name. Here is the implementation:
var path = string.Format(this.FileTemplate, DateTime.Now, state.Logger);
Custom formatters and sinks
Loggers in ScyberLog are a composition of a message formatter and some number of mesage sinks. If you need to modify the format of any log messages or write to another datasource you can implement a new ILogFormatter or ILogSink respectively and register them with the service collection. Both of these interfaces implement the IKeyedItem interface, which you can use to specify a string key with which you can reference your sinks/formatters in the configuration: