内蒙古知名网站建设,广告模板图片,wordpress git 伪静态,wordpress上传视频人50前言Asp.Net Core中有一个不受人重视的属性HttpContext.TraceIdentifier#xff0c;它在链路追踪中非常有用#xff0c;下面是官方的定义:在项目中一般会将该字段输出到每一条日志中#xff0c;也可以将此Id作为通用响应字段返回前端#xff0c;后续可以根据该属性和日志匹… 前言Asp.Net Core中有一个不受人重视的属性HttpContext.TraceIdentifier它在链路追踪中非常有用下面是官方的定义:在项目中一般会将该字段输出到每一条日志中也可以将此Id作为通用响应字段返回前端后续可以根据该属性和日志匹配快速定位整个链路日志。在本地开发时我通常观察到该值的格式大概这个样子0HLEACIU86PT6:0000000D在生产环境中查看日志时却不是这种格式而是Guid格式虽然都是唯一标识都能满足我的需要但是为什么会产生这一差异令我困惑最初以为是第三方日志组件对该字段进行了赋值在我的不懈努力下最终确定该差异的原因是部署方式差异导致分享给各位。差异对比创建一个Asp.Net Core新项目在示例代码中添加一行日志打印该属性[HttpGet(Name GetWeatherForecast)]
public IEnumerableWeatherForecast Get()
{_logger.LogInformation(Request.HttpContext.TraceIdentifier);return Enumerable.Range(1, 5).Select(index new WeatherForecast{Date DateTime.Now.AddDays(index),TemperatureC Random.Shared.Next(-20, 55),Summary Summaries[Random.Shared.Next(Summaries.Length)]}).ToArray();
}Kestre部署时的表现在VS中使用控制台启动项目调用几次接口输出如下可见TraceIdentifier有下面两部分组成{ConnectionId}:{Request number}第一部分ConnectionId标识同一次连接第二部分Request number标识当前是该连接的第n次请求起到计数的作用。而两者的组成{ConnectionId}:{Request number}就可以标识唯一一次请求。IIS部署时的表现用上面的的程序不做任何更改在VS中IIS Express启动,调用几次接口输出如下,由于没使用文件日志IIS Express启动时没有窗口可以看输出只能通过VS的调试窗口查看输出如下这里可以很明显地看出我们打印的TraceIdentifier是GUID格式。差异的原因本地开发时我一般不会选择IIS Express启动因为它速度慢也不能方便的查看日志输出。所以正如上文测试的那样我在本地使用只看到一种格式{ConnectionId}:{Request number}。我们生产环境是部署在Windows Server中而在windows下部署使用IIS托管则比使用控制台更加安全稳定所以这种部署方式输出的TraceIdentifier和上文中使用IIS Express表现是一致的。那为何不同的部署方式产生该差异呢其实这是Asp.Net Core设计使然。在IIS上它(TraceIdentifier)来自HTTP.sys内核驱动程序并暴露给应用程序以便您可以跟踪该ID从内核到应用程序并返回到内核它的值来自IIS生成并传递给我们的应用。使用Kestrel请求不需要iis对其进行转发我们的应用程序就是链路的第一个程序没有程序会传给它一个链路ID所以程序自己需要生成一个也就是我们看到的这种{ConnectionId}:{Request number}。总结在不同的部署方式下Asp.Net Core对TraceIdentifier有不同的表现是程序设计上的一种严谨。在IIS部署时该属性值来自IIS内核的传递以便我们可以跟踪IIS内核到我们的程序也保持了IIS式的风格。
