在之前我们简单介绍了 .NET Core 中的 DI组件，没来及了解的童鞋可以翻翻我之前的文章。 接下来会对 .NET Core 中的 Logging 进行介绍。 本文中使用了“Microsoft.Extensions.Logging.Console”做为输出目标，后续文章会详解。
Logging 中的三剑客
可以看到 Logging 的核心抽象就是三个接口，分别是：
ILogger：负责具体的日志写入逻辑，如：FileLogger，ConsoleLogger，SQLLogger，ElasticsearchLogger 等。
ILoggerProvider：用来创建记录器，一般和Logger配套使用，相当于单个Logger类型的工厂接口。
ILoggerFactory：记录器工厂，直接面向使用者的，使用者可以通过记录器工厂添加记录器提供程序和创建记录器。
这几个核心抽象位于 NuGet包：“Microsoft.Extensions.Logging.Abstractions”中。
回到目录
日志等级
在.NET Core提供的日志抽象中提供了7个日志等级（比一般的日志组件多提供了一个Trace和None），分别是：
Trace
包含最详细消息的日志。这些消息可能包含敏感的应用程序数据。默认情况下禁用这些消息，并且不应在生产环境中启用这些消息。
Debug
在开发过程中用于交互式调查的日志。这些日志应主要包含对调试有用的信息，不具有长期价值。
Information
跟踪应用程序的一般流程的日志。这些日志应具有长期价值。
Warning
突出显示应用程序流中异常或意外事件的日志，但是否则不会导致应用程序执行停止。
Error
当当前执行流程由于失败而停止时，会突出显示的日志。这些应该指示当前活动中的故障，而不是应用程序范围的故障。
Critical
描述不可恢复的应用程序或系统崩溃或灾难性的日志失败需要立即关注。
None
不用于写日志消息。指定记录类别不应写任何消息。
回到目录
简单的使用
回到目录
CreateLogger 方法
CreateLogger 方法的签名为
它提供了两个扩展方法，可以通过类型作为分类名称，如下：
如何根据类型确定分类名称？
在扩展方法内部使用了“GetTypeDisplayName(Type type)”来根据类型获取名称（里面有一些逻辑处理，但一般是采用“{命名空间}.{类型名称}”作为分类名称）。
实现传送门：https://github.com/aspnet/Logging/blob/patch/1.1.3/src/Microsoft.Extensions.Logging.Abstractions/Internal/TypeNameHelper.cs
回到目录
Log方法
logLevel
日志等级，详情见上文。
eventId（结构体，必填，可以传入 0 或 default(EventId)来充当默认值）
事件ID。
这边的事件ID是用来追踪的，类似 ErrorCode、StatusCode。这样在日志检索的时候可以通过code很方便的找到。
是一个结构体，默认为：“0”。
state（可为null）
状态。
需要记录的对象，这边可以传入任何类型，这就有点奇怪了日志不都是字符吗？
如果我传一个自建类 UserModel 进去会记录出什么信息呢？请接下来看 formatter 参数。
exception（可为null）
异常。
不多说了，如果当前上下文有异常，你丢进去就好了。
formatter（不可为null）
格式化器。
这个参数是一个委托可以看到定义“Func<TState,Exception,string>”，这个就可以解释state是非字符的情况下如何记录日志了。
这边可以通过你自己的逻辑来重建消息的内容（异常信息都会进行输出）。
如果传入null，日志组件会使用默认的格式化器替换，默认的格式化器逻辑是调用“state.ToString()”
回到目录
扩展方法
当然Logging组件为我们提供了大量扩展方法以简化我们的编码。
以下是方法存根，参数说明可以对照上文。
回到目录
EventId效果
回到目录
日志域
日志域可以聚合一类的消息，非常适合同一种类型不同维度的日志记录。
回到目录
日志过滤器
Logging提供了一个包装实现用来实现日志过滤，我们先来看看使用。
可以看到可以通过制定 CategoryName 及最小日志等级来控制日志是否输出，这边有个有趣的事情。
就是 CategoryName 可以模糊匹配。
在 Logging 组件内部挡识别到 CategoryName 为：“ConsoleApp.MyClass”时会把这个分类名称分割为：
“ConsoleApp.MyClass”
“ConsoleApp”
ps：如果你的命名空间中存在多个“.”符号则还会被分割。
分割完成之后会将这些 Key 拿去与“FilterLoggerSettings”中的字典表进行匹配，优先最大匹配，也就是说如果我们配置了“ConsoleApp.MyClass”这条项目，则优先使用这条，否则继续寻找“ConsoleApp”这条项目，如果都没匹配到则使用默认的规则。
实现传送门：https://github.com/aspnet/Logging/blob/patch/1.1.3/src/Microsoft.Extensions.Logging.Filter/Internal/FilterLogger.cs
在 NLog、log4jnet 等组件中模糊匹配是采用“.*”的方式，例如：”ConsoleApp.*”，在 .NET Core 中的 Logging 中是不被支持的（把“.*”去掉实现相同的效果），这点需要注意。
注意
“.WithFilter”是使用包装的方式进行集成，所以内部会单独维护一个 FilterLogger，也就意味着所有的 LoggerProvider 必须在 FilterFactory 中进行注册，不然过滤器是不会生效的哦。以下是错误的示例：
红色框框部分的两句应该对调，“.WithFilter”应该优先调用。
回到目录
特殊的Logger => NullLogger
这个我觉得 .NET Core 是从 Orchard“偷”过来的，Orchard 满地的 NullLogger.Instance。
为什么需要 NullLogger？
在业务系统中，Logger 其实并不影响逻辑，换句话说，Logger如果失败不应该影响业务。
在单元测试时 Logger 也可以忽略。
这句话肯定是对的，但在遍地DI的项目中 Logger 很有可能被开发者传入null，这时候就会影响业务的执行，那么这时候 NullLogger 非常适合做那个最糟糕的实现者。
用来替换日志记录或防止“NullReferenceException”这类异常的发生。
非常可惜的是，1.1.3版本中没有提供 NullLogger<T> 这样的实现。好消息是在 .NET Standard2.0 中已经提供了 NullLogger<T> 的实现。
我们下面来看看可使用的场景：
可以看到在没有添加 Logging 组件的时候日志记录也不会抛出异常。
ps：NullLogger<T> 摘抄至.NET Standard2.0中的 NullLoggerOfT.cs。 地址：https://github.com/aspnet/Logging/blob/dev/src/Microsoft.Extensions.Logging.Abstractions/NullLoggerOfT.cs
回到目录
Logger in DependencyInjection
不使用 Filter
使用 Filter
回到目录
写在最后
不得不感叹微软在 .NET Core 中统一了非常多的常用组件，为开发者统一环境提供了极大的方便。
后续的文章会分享如何集成第三方 Logging 组件，比如：NLog、log4jnet、Exceptionless 等。
