NLog日志记录器名称随机变更问题咨询

我之前也碰到过类似的NLog BufferingWrapper搭配自定义日志抽象层时的LoggerName异常问题，结合你的场景来拆解下原因和解决办法：

原因分析 #

• BufferingWrapper的延迟输出特性：这个目标会把日志事件缓存起来，达到指定条件（比如缓冲数量、时间）后才批量输出。如果你的自定义LogBuilder在创建日志事件时，没有显式固定LoggerName，而是依赖NLog的当前上下文，那么当缓冲的日志最终输出时，上下文可能已经被后续的日志请求（比如来自Program的调用）修改，导致缓存的日志事件被错误地覆盖了LoggerName。
• 自定义抽象层的上下文漏洞：你的LogBuilder实现可能复用了同一个NLog Logger实例，或者在构建日志事件时没有明确指定LoggerName。当迭代过程中不同的调用方（LogBuilder和Program）交替发起日志请求时，缓冲的日志事件会混淆不同上下文的LoggerName。
• .NET Core 3.0生命周期的潜在影响：如果你的LoggingService或LogBuilder是单例生命周期，那么在迭代过程中，不同的调用方会共享同一个实例，没有为每个日志请求隔离对应的LoggerName上下文，就会出现这种随机变更的情况。

解决方案 #

1. 显式固定每个日志事件的LoggerName #

在LogBuilder的实现中，创建日志事件时不要依赖NLog的默认上下文，而是显式指定对应的LoggerName。比如初始化LogBuilder时传入固定的名称，或者绑定到当前类的名称：

public class LogBuilder : IFluentLogBuilder
{
    private readonly ILogger _logger;
    private readonly string _fixedLoggerName;

    public LogBuilder(string loggerName)
    {
        _fixedLoggerName = loggerName;
        _logger = LogManager.GetLogger(loggerName);
    }

    public IFluentLogBuilder Info(string message)
    {
        // 显式使用固定的LoggerName构建日志事件
        _logger.ForLogger(_fixedLoggerName)
               .Info(message);
        return this;
    }
}

2. 调整BufferingWrapper的配置 #

如果业务允许，可以先尝试调整缓冲规则，验证是否是缓冲导致的问题：

• 临时将bufferSize设为1，让日志立即输出，看LoggerName是否还会乱序：

<target name="bufferedTarget" xsi:type="BufferingWrapper" bufferSize="1">
    <!-- 你的实际输出目标，比如Console、File等 -->
    <target xsi:type="Console" name="consoleTarget" />
</target>

• 如果必须保留批量缓冲，确保所有日志事件在创建时就已经设置好正确的LoggerName，避免输出时依赖上下文。

3. 隔离日志实例的上下文 #

在依赖注入配置中，为不同的调用方提供独立的日志实例，确保LoggerName与调用方类型绑定：

// 在Startup.cs的ConfigureServices中配置
services.AddScoped<ILog>(provider =>
{
    // 获取当前请求的调用类型（可以通过调用栈或DI上下文获取）
    var callerType = ...; 
    var loggerName = callerType.Name;
    return new LoggingService(new LogBuilder(loggerName));
});

4. 检查全局上下文污染 #

确保迭代过程中没有意外修改NLog的全局上下文（比如MappedDiagnosticsLogicalContext、ThreadContext），这些上下文的变更可能会影响缓冲日志事件的属性。

内容的提问来源于stack exchange，提问作者Tim Long