Asp.Net Core2.2 源码阅读系列——控制台日志源码解析

  为了让我们第一时间知道程序的运行状态，asp.net core 添加了默认的日志输出服务。这看起来并没有什么问题，对于开发人员也相当友好，但如果不了解日志输出的细节，也有可能因为错误的日志级别配置导致性能问题，笔者的同事在一次进行性能测试的时候被输出日志误导，与其讨论分析了测试源码，排除业务代码因素，后来联想到应该是由于默认的日志输出导致（默认的日志级别 microsoft 是 inforamtion），随后将日志级别调高，性能立即飙升，问题解决。

  虽然问题得到解决，但笔者脑中的对于到底为何日志输出会导致性能下降的疑问没有解决，一切查资料的方式，都不及先看源码来得直接，于是在github上拉取源码，经过详细的阅读分析，终于了解了技术细节，找到了高并发下，控制台日志输出导致性能低下的真正原因。

1.首先要弄清楚默认日志服务是如何添加的？

  asp.net core程序在启动时，iwebhostbuilder createdefaultbuilder(args) 方法中会为我们注册一些默认服务，这其中就包含默认的日志输出服务[github源码地址]：

public static void main(string[] args)
{
    createwebhostbuilder(args).build().run();
}

public static iwebhostbuilder createwebhostbuilder(string[] args) =>
    webhost.createdefaultbuilder(args)
    .usestartup<startup>();

//部分源码
public static iwebhostbuilder createdefaultbuilder(string[] args)
{
      var builder = new webhostbuilder();
      ...

      builder.usekestrel((buildercontext, options) =>
      {
          options.configure(buildercontext.configuration.getsection("kestrel"));
      })
      .configureappconfiguration((hostingcontext, config) =>
      {
          ...
      })
      .configurelogging((hostingcontext, logging) =>
      {
          logging.addconfiguration(hostingcontext.configuration.getsection("logging"));
          logging.addconsole(); //手动高亮
          logging.adddebug(); //手动高亮
          logging.addeventsourcelogger(); //手动高亮
      })
      .configureservices((hostingcontext, services) =>
      {
        ...
      })
      .useiis()
      .useiisintegration()
      .usedefaultserviceprovider((context, options) =>
      {
          options.validatescopes = context.hostingenvironment.isdevelopment();
      });

      return builder;
}

ps：如果还想了解默认添加的其他服务详细细节，可以参看hosting源码地址

2. 日志源码

  目前 asp.net core 已经将扩展插件统统挪到 [aspnet/extensions] 仓库下，包含了所有 asp.net core 所使用的扩展组件，如日志，配置等，如需查找 microsoft.extensions.* 命名空间下的源码，可以参考这个仓库。

  打开目录 extensions/src/logging/ ，可以看到日志相关的组件均在这个文件夹下，这里简单说下主要包含的project：

1. 日志抽象层，主要负责logger以及loggerfactory接口定义和默认实现，为ioc提供扩展方法

• microsoft.extensions.logging.abstractions
• microsoft.extensions.logging

1. 日志配置

• microsoft.extensions.logging.configuration

1. 日志具体实现

• microsoft.extensions.logging.console
• microsoft.extensions.logging.debug
• microsoft.extensions.logging.eventlog

  先来看下代码图：

   上图可以看到，核心类主要有以下几个：

1. consoleloggerprovider 实现了iloggerprovider接口，主要负责创建consolelogger
2. consoleloggersettings consolelogger日志配置类
3. consolelogger 实现ilogger接口，日志输出最终的执行类

重要！篇幅原因，以下源码均做了精简，如有需要可以点击文件名连接直接查看github源文件。

先来看 consoleloggerprovider.cs 源码:

public class consoleloggerprovider : iloggerprovider
{
    private readonly concurrentdictionary<string, consolelogger> _loggers = new concurrentdictionary<string, consolelogger>();//手动高亮

    private readonly func<string, loglevel, bool> _filter;
    private iconsoleloggersettings _settings;
    private readonly consoleloggerprocessor _messagequeue = new consoleloggerprocessor();//手动高亮
    private static readonly func<string, loglevel, bool> falsefilter = (cat, level) => false;

    //通过ioptionmonitor<> 实现动态修改日志参数功能，比如日志级别
    public consoleloggerprovider(ioptionsmonitor<consoleloggeroptions> options)
    {
        // filter would be applied on loggerfactory level
        _filter = truefilter;
        _optionsreloadtoken = options.onchange(reloadloggeroptions);
        reloadloggeroptions(options.currentvalue);
    }

    //3.0中将移除此构造函数
    public consoleloggerprovider(iconsoleloggersettings settings)
    {
        _settings = settings;
        if (_settings.changetoken != null)
        {
            _settings.changetoken.registerchangecallback(onconfigurationreload, null);
        }
    }

    //动态修改日志级别
    private void reloadloggeroptions(consoleloggeroptions options)
    {
        foreach (var logger in _loggers.values)
        {
            logger.scopeprovider = scopeprovider;
        }
    }

    //通过此方法动态修改日志级别
    private void onconfigurationreload(object state)
    {
        _settings = _settings.reload();
        foreach (var logger in _loggers.values)
        {
            logger.filter = getfilter(logger.name, _settings);
        }
    }

    //创建日志组件，注意，每个日志category name 创建一个日志实例，
    //所以可以根据不同的name设置不通的日志级别，达到细粒度控制
    public ilogger createlogger(string name)
    {
        return _loggers.getoradd(name, createloggerimplementation);
    }

    private consolelogger createloggerimplementation(string name)
    {
        return new consolelogger(name, getfilter(name, _settings), null, _messagequeue) { };
    }

    private func<string, loglevel, bool> getfilter(string name, iconsoleloggersettings settings)
    {
        if (settings != null)
        {
            foreach (var prefix in getkeyprefixes(name))
            {
                loglevel level;
                if (settings.trygetswitch(prefix, out level))
                {
                    return (n, l) => l >= level;
                }
            }
        }
        return falsefilter;
    }

    //日志级别匹配方式，比如name为 "a.b.c"，则依次匹配 "a.b.c","a.b", "a" 
    private ienumerable<string> getkeyprefixes(string name)
    {
        while (!string.isnullorempty(name))
        {
            yield return name;
            var lastindexofdot = name.lastindexof('.');
            if (lastindexofdot == -1)
            {
                yield return "default";
                break;
            }
            name = name.substring(0, lastindexofdot);
        }
    }
}

  可以看见，consoleloggerprovider 持有一个线程安全的字典_loggers，用以保证每个category name（也就是业务代码中构造函数中的 ilogger<t> 中的 nameof(t)）有且仅有一个ilogger 实例，之所以这么做，是为了可以更加细粒度控制每个logger的日志输出细节，比如log level。同时，可以通过 ioperationmonitor<> 实现动态日志细节配置控制。

  另外还有一个名为 _messagequeue 的实例在 consolelogger 构造时传进去，从名字看来似乎对日志输出做了排队处理，我们稍后再看。

再来看 consolelogger.cs 源码:

public class consolelogger : ilogger
{
    private readonly consoleloggerprocessor _queueprocessor;
    private func<string, loglevel, bool> _filter;

    [threadstatic]//手动高亮
    private static stringbuilder _logbuilder;

    static consolelogger()
    {
        var loglevelstring = getloglevelstring(loglevel.information);
    }

    internal consolelogger(string name, func<string, loglevel, bool> filter, iexternalscopeprovider scopeprovider, consoleloggerprocessor loggerprocessor)
    {
        name = name;
        filter = filter ?? ((category, loglevel) => true);
        _queueprocessor = loggerprocessor;
    }

    public string name { get; }

   //日志写入接口实现
    public void log<tstate>(loglevel loglevel, eventid eventid, tstate state, exception exception, func<tstate, exception, string> formatter)
    {
        if (!isenabled(loglevel)) return;

        var message = formatter(state, exception);
        if (!string.isnullorempty(message) || exception != null)
        {
            writemessage(loglevel, name, eventid.id, message, exception);
        }
    }

    // 日志通过stringbuilder进行装配
    public virtual void writemessage(loglevel loglevel, string logname, int eventid, string message, exception exception)
    {
        var logbuilder = _logbuilder;
        _logbuilder = null;

        if (logbuilder == null)
        {
            logbuilder = new stringbuilder();
        }

        var loglevelstring = getloglevelstring(loglevel);
        // category and event id
        logbuilder.append(_loglevelpadding);
        logbuilder.append(logname);
        logbuilder.append("[");
        logbuilder.append(eventid);
        logbuilder.appendline("]");

        if (!string.isnullorempty(message))
        {
            // message
            logbuilder.append(_messagepadding);

            var len = logbuilder.length;
            logbuilder.appendline(message);
            logbuilder.replace(environment.newline, _newlinewithmessagepadding, len, message.length);
        }

        if (exception != null)
        {
            logbuilder.appendline(exception.tostring());
        }

        var haslevel = !string.isnullorempty(loglevelstring);
        // queue log message
        _queueprocessor.enqueuemessage(new logmessageentry() //装配完成日志入队
        {
            message = logbuilder.tostring(),
            messagecolor = defaultconsolecolor,
            levelstring = haslevel ? loglevelstring : null,
        });

        logbuilder.clear();
        if (logbuilder.capacity > 1024)
        {
            logbuilder.capacity = 1024;
        }
        _logbuilder = logbuilder;
    }

    public bool isenabled(loglevel loglevel)
    {
        if (loglevel == loglevel.none)
        {
            return false;
        }

        return filter(name, loglevel);
    }

    //日志最终记录字段和loglevel中的枚举名称通过此方法映射
    private static string getloglevelstring(loglevel loglevel)
    {
        switch (loglevel)
        {
            case loglevel.trace:
                return "trce";
            case loglevel.debug:
                return "dbug";
            case loglevel.information:
                return "info";
            case loglevel.warning:
                return "warn";
            case loglevel.error:
                return "fail";
            case loglevel.critical:
                return "crit";
            default:
                throw new argumentoutofrangeexception(nameof(loglevel));
        }
    }
}

  此类是对ilogger接口的简单实现，可以看出，在调用log() 接口时，内部调用了writemessage()方法，使用stringbuilder 对日志内容进行了拼接，然后果然丢进了_queueprocessor队列，并没有立即输出。

  值得注意的是，笔者看到writemessage()方法中的 _logbuilder.append() 日志内容时，没加任何锁，立即怀疑这不是会有线程安全问题么？然后抬头一看，_logbuilder的字段定义上加了 [threadstatic] 标签，相比于对这个方法加锁，对这个字段设置为线程静态字段才是完美的方案，不得不感叹微软程序员的严谨性！

最后看下 consoleloggerprocessor.cs，寻找最终答案:

 public class consoleloggerprocessor : idisposable
    {
        private const int _maxqueuedmessages = 1024;

        private readonly blockingcollection<logmessageentry> _messagequeue = new blockingcollection<logmessageentry>(_maxqueuedmessages);
        private readonly thread _outputthread;

        public iconsole console;

        public consoleloggerprocessor()
        {
            // 开启消费阻塞队列线程
            _outputthread = new thread(processlogqueue)
            {
                isbackground = true,
                name = "console logger queue processing thread"
            };
            _outputthread.start();
        }

        public virtual void enqueuemessage(logmessageentry message)
        {
            if (!_messagequeue.isaddingcompleted)
            {
                try
                {
                    //入队操作
                    _messagequeue.add(message);
                    return;
                }
                catch (invalidoperationexception) { }
            }
        }

        //消费队列
        private void processlogqueue()
        {
            try
            {
                foreach (var message in _messagequeue.getconsumingenumerable())
                {
                    writemessage(message);
                }
            }
            catch
            {
                try
                {
                    _messagequeue.completeadding();
                }
                catch { }
            }
        }
    }

  以上代码解释了为何在并发情况下，控制台日志输出会导致性能降低的原因：
该类中有一个blockingcollection<> 阻塞队列，最大长度1024，用于实现日志输出的生产消费模型，再看 enqueuemessage()方法，如果阻塞队列中已经达到1024条日志，则所有生产者将被阻塞。也就是说：一旦日志生产速度远远大于队列消费速度，生产者将会集中等待队列消费后才能竞争入队后返回，引发了性能瓶颈

  到此，终于弄清楚之前的性能测试为何会受日志控制台输出的影响，对底层代码的分析，会加深对此类问题的理解，不但对之后排查类似问题有帮助，也让我们对生产消费模型场景有了更深的理解。

后记

  笔者此次对日志相关源码还做了更多深入的阅读，同时依照 microsoft.extesions.logging 中的接口实现了自定义日志组件，用于在生产中，从底层对很多信息进行获取和记录，比如traceid，在这个翻阅的过程中，感受到通过阅读源码，可以更加直接的理解 asp.net core 相关的设计思想，以及代码实现，对于理解整体框架有极大的帮助，笔者后续也会继续阅读其他相关源码。对于目前在使用.net core 的同学，希望你同我一样，对了解事务的本质保持好奇心，持之以恒！