HttpContext.TraceIdentifier那严谨的设计

前言

Asp.Net Core中有一个不受人重视的属性HttpContext.TraceIdentifier，它在链路追踪中非常有用，下面是官方的定义:

在项目中一般会将该字段输出到每一条日志中，也可以将此Id作为通用响应字段返回前端，后续可以根据该属性和日志匹配，快速定位整个链路日志。在本地开发时我通常观察到该值的格式大概如下长这个样子0HLEACIU86PT6:0000000D，在生产环境中查看日志时，却不是这种格式，而是Guid格式，虽然都是唯一标识，都能满足我的需要，但是为什么会产生这一差异令我困惑，最初以为是第三方日志组件对该字段进行了赋值，在我的不懈努力下，最终确定该差异的原因是部署方式差异导致，分享给各位。

差异对比

创建一个Asp.Net Core新项目，在示例代码中添加一行日志，打印该属性

[HttpGet(Name = "GetWeatherForecast")]
public IEnumerable<WeatherForecast> 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式的风格。