.Net Core中的日志Logging使用以及源码解析
在.Net Core中系统自带的集成了日志系统,看一下如何使用:
第一步先添加LogProvider,这个是为了告诉容器我们日志输出的来源,LogProvider的目的是创建Logger,在Asp.Net Core中默认添加了3个Provider:
.ConfigureLogging((hostingContext, logging) => { logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging")); logging.AddConsole(); logging.AddDebug(); logging.AddEventSourceLogger(); })
这里添加的LoggerProvider最终都会被注入到LoggerFactory中,用于创建ILogger。
上述代码里还看到了AddConfiguration,这是通过配置添加日志过滤条件。后面会具体讲解。
添加完Provider之后,就可以从容器中获取日志对象,获取的时候有两种类型可以获取:
- ILogger<T>:直接获取日志输出对象。
- ILoggerFactory:获取日志工厂,然后调用ILogger CreateLogger(string categoryName);这个方法产生一个日志输出对象。实际上第一种方式,直接获取的ILogger<T,>内部也包含了一个ILogger对象,它最终也是调用的内部的ILogger进行操作,自己本身没有干任何事情。可以看一下ILogger<T>的实现类代码:
public class Logger<T> : ILogger<T> { private readonly ILogger _logger; /// <summary> /// Creates a new <see cref="Logger{T}"/>. /// </summary> /// <param name="factory">The factory.</param> public Logger(ILoggerFactory factory) { if (factory == null) { throw new ArgumentNullException(nameof(factory)); } _logger = factory.CreateLogger(TypeNameHelper.GetTypeDisplayName(typeof(T))); } IDisposable ILogger.BeginScope<TState>(TState state) { return _logger.BeginScope(state); } bool ILogger.IsEnabled(LogLevel logLevel) { return _logger.IsEnabled(logLevel); } void ILogger.Log<TState>(LogLevel logLevel, EventId eventId, TState state, Exception exception, Func<TState, Exception, string> formatter) { _logger.Log(logLevel, eventId, state, exception, formatter); } }
从这里看出,如果以泛型的方式去获取,categoryName就是这个类的全称,基本上就等于typeof(T).FullName,这个会在后续的日志过滤中起到效果。
在Controller中使用日志
这是一个最简单的例子,实际记录日志的地方,一般不会在构造里面:
public class HomeController : Controller { public HomeController(ILogger<HomeController> loggerT, ILoggerFactory loggerFactory) { var testLog = loggerFactory.CreateLogger("Test"); loggerT.LogInformation("Info"); testLog.LogInformation("Info"); } }
讲到这里你可能会有一些疑问:我添加了多个LogProvider,自然会产生多个ILogger,那这里通过工厂类产生的ILogger到底是哪一个?答案是:一个都不是!这里通过工厂产生的ILogger是系统的默认实现Microsoft.Extensions.Logging.Logger。而在这个默认实现Logger里,有一个LoggerInformation数组。LoggerInformation包含了这些LogProvider产生的ILogger和一些过滤条件,在不添加任何过滤条件的情况下,上述的代码同时会记录到3个不同的地方。
添加了多少个LogProvider,这个LoggerInformation数组的长度就为多少。LoggerInformation和LogProvider一一对应。
另外,如果想以注入的方式去获取ILogger是行不通的,因为在初始化的时候,不会向容器中注册ILogger的实现,只会注册ILoggerFactory和ILogger<T>。值得一提的是,每产生一个ILogger(默认实现Logger)都会根据CategoryName缓存起来。
日志过滤
在讲日志过滤的时候,我们要先明确日志过滤的筛选的条件有哪些:
- Category:这个值就是在创建ILogger(系统默认的实现Logger)时,传递的那个categoryName参数。对于以ILogger<T>方式获取的日志对象,这个值就是T的类型全称。
- ProviderType:这个值就很简单,就是创建该ILogger的LogProvider的类型。
- LogLevel:日志记录的级别,这是一个系统定义的枚举类型:
public enum LogLevel { /// <summary> /// Logs that contain the most detailed messages. These messages may contain sensitive application data. /// These messages are disabled by default and should never be enabled in a production environment. /// </summary> Trace = 0, /// <summary> /// Logs that are used for interactive investigation during development. These logs should primarily contain /// information useful for debugging and have no long-term value. /// </summary> Debug = 1, /// <summary> /// Logs that track the general flow of the application. These logs should have long-term value. /// </summary> Information = 2, /// <summary> /// Logs that highlight an abnormal or unexpected event in the application flow, but do not otherwise cause the /// application execution to stop. /// </summary> Warning = 3, /// <summary> /// Logs that highlight when the current flow of execution is stopped due to a failure. These should indicate a /// failure in the current activity, not an application-wide failure. /// </summary> Error = 4, /// <summary> /// Logs that describe an unrecoverable application or system crash, or a catastrophic failure that requires /// immediate attention. /// </summary> Critical = 5, /// <summary> /// Not used for writing log messages. Specifies that a logging category should not write any messages. /// </summary> None = 6, }
这几个参数和ILogger(LogProvider产生的)会一起被保存到LoggerInformation这个对象中。在LoggerInformation还有一个属性也是用做日志过滤的:
public Func<string, string, LogLevel, bool> Filter { get; set; }
这是一个委托需要三个参数,分别代表Category,ProviderType,LogLevel,返回布尔值,代表是否启用该日志类型。当有了这些信息后,每当使用ILogger(系统的默认实现Logger)进行日志书写时,会循环遍历LoggerInformation数组对象,这样就可以独立控制每一个LogProvider产生的ILogger对象,根据不同的Provider,Category和LogLevel来决定是否需要输出日志。
接下来的问题就是,如何配置过滤规则?配置过滤规则唯一途径就是配置LoggerFilterOptions这个对象。如何自己配置一个Option对象,请参考我同系列的前一篇文章。
系统提供了一系列的的扩展方法帮我们去配置这个对象,详情可以参考:https://github.com/aspnet/Extensions/blob/master/src/Logging/Logging/src/FilterLoggingBuilderExtensions.cs,也有基于配置的扩展,其核心代码是:https://github.com/aspnet/Extensions/blob/master/src/Logging/Logging.Configuration/src/LoggerFilterConfigureOptions.cs 那这个LoggerFilterOptions又是什么呢,一起看一下源代码:
public class LoggerFilterOptions { /// <summary> /// Gets or sets the minimum level of log messages if none of the rules match. /// </summary> public LogLevel MinLevel { get; set; } /// <summary> /// Gets the collection of <see cref="LoggerFilterRule"/> used for filtering log messages. /// </summary> public IList<LoggerFilterRule> Rules { get; } = new List<LoggerFilterRule>(); }
系统提供的所有扩展方法,都是往这个对象的Rules添加Rule,然后在创建一个ILogger(LogProvider创建的)的时候根据一定的规则去匹配到属于这个ILogger(LogProvider创建的)的那条Rule,赋值给LoggerInformation的Filter属性。也就是说,即使有很多条Rule,但是最终只会找到最符合条件的那条Rule。如果一条都找不到,那就使用MinLevel。默认情况下MinLevel是Information。而这个LoggerFilterRule包含的属性,就是前面提到的那几个筛选条件:
public class LoggerFilterRule { public LoggerFilterRule(string providerName, string categoryName, LogLevel? logLevel, Func<string, string, LogLevel, bool> filter) { ProviderName = providerName; CategoryName = categoryName; LogLevel = logLevel; Filter = filter; } /// <summary> /// Gets the logger provider type or alias this rule applies to. /// </summary> public string ProviderName { get; } /// <summary> /// Gets the logger category this rule applies to. /// </summary> public string CategoryName { get; } /// <summary> /// Gets the minimum <see cref="LogLevel"/> of messages. /// </summary> public LogLevel? LogLevel { get; } /// <summary> /// Gets the filter delegate that would be applied to messages that passed the <see cref="LogLevel"/>. /// </summary> public Func<string, string, LogLevel, bool> Filter { get; } public override string ToString() { return $"{nameof(ProviderName)}: '{ProviderName}', {nameof(CategoryName)}: '{CategoryName}', {nameof(LogLevel)}: '{LogLevel}', {nameof(Filter)}: '{Filter}'"; } }
那查找Rule的匹配规则又是什么呢?核心代码如下(可以直接看后面的解释):
internal class LoggerRuleSelector { public void Select(LoggerFilterOptions options, Type providerType, string category, out LogLevel? minLevel, out Func<string, string, LogLevel, bool> filter) { filter = null; minLevel = options.MinLevel; // Filter rule selection: // 1. Select rules for current logger type, if there is none, select ones without logger type specified // 2. Select rules with longest matching categories // 3. If there nothing matched by category take all rules without category // 3. If there is only one rule use it's level and filter // 4. If there are multiple rules use last // 5. If there are no applicable rules use global minimal level var providerAlias = ProviderAliasUtilities.GetAlias(providerType); LoggerFilterRule current = null; foreach (var rule in options.Rules) { if (IsBetter(rule, current, providerType.FullName, category) || (!string.IsNullOrEmpty(providerAlias) && IsBetter(rule, current, providerAlias, category))) { current = rule; } } if (current != null) { filter = current.Filter; minLevel = current.LogLevel; } } private static bool IsBetter(LoggerFilterRule rule, LoggerFilterRule current, string logger, string category) { // Skip rules with inapplicable type or category if (rule.ProviderName != null && rule.ProviderName != logger) { return false; } if (rule.CategoryName != null && !category.StartsWith(rule.CategoryName, StringComparison.OrdinalIgnoreCase)) { return false; } if (current?.ProviderName != null) { if (rule.ProviderName == null) { return false; } } else { // We want to skip category check when going from no provider to having provider if (rule.ProviderName != null) { return true; } } if (current?.CategoryName != null) { if (rule.CategoryName == null) { return false; } if (current.CategoryName.Length > rule.CategoryName.Length) { return false; } } return true; } }
在配置规则时ProviderName默认应该是类的全称,而上面提到的ProviderAlias指的是该类的别称,在类上面添加ProviderAliasAttribute为它定义一个别称,方便配置。
再来看IsBetter方法:
- 如果传进来的Rule应用于某一个具体的Provider,并且和当前Log的Provider不一致,则直接返回False,因为不匹配
- 如果传进来的的Rule应用于某一个具体的Category(默认是类的全名),并且和当前Log的Category不匹配,则返回False,因为不匹配
- 如果当前的Rule应用于某一个具体的Provider,并且传进来的Rule不是应用于某一个具体的Provider,则返回False,因为当前的优先级更高
- 如果当前的Rule不是应用于某一个具体的Provider,并且传进来的Rule是应用于某一个具体的Provider(由于第一点的存在,传进来的Rule的Provider一定是和当前Log一致的,由于第二点的存在,如果传进来的Rule包含Category,则一定和当前的Log一致),则返回True,因为传进来的优先级更高
- 如果当前的Rule是应用于某一个具体的Category,并且传递进来的Rule不是应用于某一个具体的Category,则返回False,因为当前优先级更高
- 如果当前的Rule是应用于某一个具体的Category,并且当前传递进来的Rule也是应用于某一个具体的Category,但是当前的匹配度更高(字符串长度越长),则返回False,因为当前的优先级更高
- 其余都返回True
那么最终Rule的匹配度,由低到高应该是:
- ProviderName: null,CategoryName:null
- ProviderName: null,CategoryName:Matched(匹配的长度越长,说明越匹配)
- ProviderName: Matched,CategoryName:null
- ProviderName: Matched,CategoryName:Matched(匹配的长度越长,说明越匹配)
CategoryName的匹配度指的是字符串长度。如果一个Rule都没找到,那就使用MinLevel。
最佳实践
使用配置文件,去配置日志过滤条件,注意:使用配置文件时,只能设置特定的Provider和Category的LogLevel,不能指定委托类型的Filter。想要使用Filter,只能用编码的方式配置。来看一个日志配置实例:
"Logging": { "LogLevel": { "Default": "Debug" }, "Console": { "LogLevel": { "Default": "Warning", "CoreLogging.Controllers": "Error", "CoreLogging.Controllers.HomeController": "Info" } } }
在Logging下面的直接子节点LogLevel下面配置的,代表Proivder为null,同时子节点的名称代表Category,值代表LogLevel。
而Logging下面的其它直接子节点,节点名称代表ProviderName。其下的LogLevel子节点下面的子节点,名称代表Category,值代表LogLevel。
另外Category的值为Default,最终解析的时候会解析成null,不区分大小写。
这里的Console可以使用Microsoft.Extensions.Logging.Console.ConsoleLoggerProvider代替,因为ConsoleLoggerProvider有一个特性别称Console,所以可以不写全称。[ProviderAlias("Console")]
最终这个配置会被解释成:
- 非Console的日志记录时,只记录日志级别高于Debug
- Console的日志,如果Category不以CoreLogging.Controllers开头,则只记录级别高于Warning的
- Console的日志,如果Category以CoreLogging.Controllers开头但不以CoreLogging.Controllers.HomeController开头,则只记录级别高于Error的
- Console的日志,如果Category以CoreLogging.Controllers.HomeController开头,则只记录级别高于Info的
文中提到的源码都在https://github.com/zhurongbo111/AspNetCoreDemo/tree/master/03-Logging