Skip to end of metadata
Go to start of metadata

Crosslight Logging Framework provides a better way to log your application. The Crosslight Logging Framework allows you to filter your log entries by severity levels, categories, and priority. You can also implement your own custom filtering to filter your log entries. The filtering capability allows you to log everything in your application without compromising the performance of your application.

You have fine-grained control over which logs should be written by configuring the LogWriter. A good way to log your application is to log everything at critical entry points that may have valuable information for the application, since excessive logging might slow down your application.

To learn more about the Crosslight logging concept in general, see Implementing Application Logging.

On this page:

Category and Source Level Filters

A log entry has two main properties that are commonly used for log filtering which are Category and Severity LevelThe category is automatically filled by the ILog object. By default, the category is set to the full class name where the ILog object is referenced. So if you perform logging in MyApp.ViewModels.MyModule class, the category will be MyApp.ViewModels.MyModule, which is the full qualified name of the class. This comply to the per-class logging concept, where all log entry category should indicates where the log is created.

The severity level is defined automatically by the logging API itself, for instance, the ILog.Fatal method will create a log with Fatal severity level. The following table describes the mapping of API and severity levels available in Crosslight Logging Framework.

APISeverity Level
ILog.Fatal
ILog.FatalFormat 
Fatal
ILog.Error
ILog.ErrorFormat 
Error

ILog.Warn
ILog.WarnFormat 

Warn
ILog.Info
ILog.InfoFormat 
Info
ILog.Debug
ILog.DebugFormat 
Debug
ILog.Trace
ILog.TraceFormat 
Start | Stop | Suspend | Resume | Transfer

To learn more how to use these APIs, see Writing Log Entries.
Crosslight Logging Framework provides a built-in category filtering that works in conjunction with severity level. When adding a log filter, you specify the source level which is equivalently mapped to the severity level. In addition, a source level will always include the priority of the lower levels during filtering. For instance, the Error level automatically include logs written with Error and Fatal methods, whereas Info level automatically include all logs written with InfoWarnError and Fatal methods. See the following table for more details.

Source LevelImpact
OffNo logs will be written.
FatalOnly logs with Fatal severity level will be written.
ErrorOnly logs with Fatal and Error severity level will be written.
WarnOnly logs with Fatal, Error and Warning severity level will be written.
InfoOnly logs with Fatal, Error, Warning and Info severity level will be written.
DebugOnly logs with Fatal, Error, Warning, Info and Debug severity level will be written.
Activity TracingOnly logs with Fatal, Error, Warning, Info, Debug, Start, Stop, Suspend, Resume and Transfer severity level will be written.
AllAll logs will be written.

By understanding the source level concept, you can now create a log filter based on specific category and source level by using the API such as shown in the following code example.

With the above code, only logs with Error and Fatal severity level within the ApplicationLoggingSamples.ViewModels namespace will be processed. The rest of classes, since they are not explicitly defined in the filter, will use the source level assigned to the root logger which default to Info.

The following table shows several examples of the category and severity filter, and how each log filter produces different impact.

Category FilterLevel FilterImpact
RootInfoOnly logs with Info, Warn, Error and Fatal severity level for non-filtered classes will be processed.
MyApplication.ServicesErrorOnly logs with Error and Fatal severity level for classes in MyApplication.Services will be processed.
MyApplication.ViewModelsAllAny severity level for classes in MyApplication.ViewModels will be processed.
MyApplication.DataOffNo log will be processed for classes in MyApplication.Data.

Implementing Additional Filters

If necessary, you can also add additional filters to your LogWriter.Filters property. You can use the built-in LogFilter that are available in Crosslight Logging Framework or create your own custom filter.

Using PriorityFilter

Crosslight Logging Framework has an additional filter called PriorityFilter. You can use this filter to filter out your log entry with certain priority level. To add priority into your log entry see, Writing Log Entries.

The following code shows you how to apply PriorityFilter to LogWriter.

Creating Custom Filter

To create a custom filter, you need to implement ILogFilterILogFilter Interfaceinterface or you can extend from LogFilter class, then perform the filtering logic at Filter(LogEntry log) method as follows.

This filter basically only allows log entry that has extra data with key equals to "MyKey".

Samples

To learn more about application logging in Crosslight and see how it works, please checkout the following samples: