我们知道日志系统有一个叫做“日志范围”的概念，它的目的在于为多次相关的日志记录创建一个上下文范围，并为这个范围提供一个唯一标识，这个标识会作为日志内容的一部分被写入。当我们在进行日志分析的时候，可以根据日志范围标识将一组原本独立的日志关联起来。这个概念对于Web应用尤为重要，因为很多情况下我们所做的日志分析都是针对某一个请求，这就要求我们必须明确地分辨出被记录下来的日志隶属于哪一个请求，只有这样才能将针对同一请求的所有日志提取出来做综合的分析以得出一个准确的结论。
从上个实例最终写入的三条日志来看，它们并不携带当前请求的标识信息。但是这不是ASP.NET Core的问题，而是我们在调用LoggerFactory的扩展方法AddConsole注册ConsoleLoggerProvider的时候并未显式开启针对日志范围的支持。为了让注册的ConsoleLoggerProvider创建的Logger能够支持日志范围，我们只需按照如下的方式在调用AddConsole方法的时候添加一个额外的参数（true）即可。
new WebHostBuilder() .ConfigureLogging(factory=>factory.AddConsole(true)) .UseKestrel() .UseStartup<Startup>() .Build() .Run();
我们再次请求应用并利用浏览器对目标地址发送两次请求，六条写入的日志将会以如下图所示的形式输出到控制台上。不同于上面的输出结果，本次输出的日志包含请求的ID（Request Id），在同一个请求下被记录下来的日志具有相同的ID。除了请求ID，记录的日志还携带了请求的路径（Request Path）。
日志范围携带的用于唯一标识当前请求的ID，同时也可以视为当前HttpContext的唯一标识，它对应着HttpContext的TranceIdentifier属性。对于DefaultHttpContext来说，针对这个属性的读写是借助一个名为HttpRequestIdentifierFeature的特性实现的，下面的代码提供了该对象对应的接口IHttpRequestIdentifierFeature和默认实现类HttpRequestIdentifierFeature的定义。
public abstract class HttpContext { //省略其他成员 public abstract string TraceIdentifier { get; set; } } public interface IHttpRequestIdentifierFeature { string TraceIdentifier { get; set; } } public class HttpRequestIdentifierFeature IHttpRequestIdentifierFeature { private string _id; private static long _requestId = DateTime.UtcNow.Ticks; private static unsafe string GenerateRequestId(long id); public string TraceIdentifier { get { return _id??(id= GenerateRequestId(Interlocked.Increment(ref _requestId))); } set { this._id = value; } } }
HttpRequestIdentifierFeature生成TraceIdentifier的逻辑很简单。如上面的代码片断所示，它具有一个静态长整型字段_requestId，其初始值为当前时间戳。对于某个具体的HttpRequestIdentifierFeature对象来说，它的TraceIdentifier属性的默认值返回的是这个字段_requestId加1之后转换的字符串。具体的转换逻辑定义在GenerateRequestId方法中，它会采用相应的算法 将指定的整数转换一个长度为13的字符串。
和开始请求处理的时间戳一样，被创建出来的日志范围实际被保存在HostingApplication的上下文对象中，它对应着Context结构的Scope属性。当HostingApplication创建这个Context对象的时候，它会从当前HttpContext中提取出请求的ID和路径，创建出这个日志范围并赋值给这个属性。整个请求的处理其实就在这个日志范围中进行，请求处理结束，当前日志范文也被回收释放。
public class HostingApplication IHttpApplication<HostingApplication.Context> { public struct Context { public HttpContext HttpContext { get; set; } public IDisposable Scope { get; set; } public long StartTimestamp { get; set; } } }
三、记录异常日志
由于ASP.NET Core在处理请求过程中导致的异常并不会导致应用终止，考虑到安全，抛出的异常的详细信息也不应该直接返回到客户端。所以在很多情况下我们根本感知不到应用发生了异常，即使感知到了，也不知道导致异常的根源在何处。在这种情况下，我们就需要使用记录的日志进行差错和纠错，因为ASP.NET Core在处理请求遇到的异常都会记录到日志中。
比如针对如下这段程序，毫无疑问它针对任何一个请求的处理都会抛出一个DivideByZeroException的异常。如果我们利用浏览器来访问站点地址，它只会得到一个状态为500的响应，并简单的提示服务端出现错误。对于宿主程序来说，我们根本就是感知不到任何异常发生。
new WebHostBuilder() .UseKestrel() .Configure(app=>app.Run(async context=> { int x = 1; int y = 0; await context.Response.WriteAsync((x / y).ToString()); })) .Build() .Run();