日志的应用，由浅入深，经验分享（二）

 在日志的应用（一）中，我们提到了日志的几个功能和技术选型，这里补充几个细节：

1. 模块化打日志，日志在线热改变模式

在产品线上，日志的层级一般都是error 层级，在线调试的情况下，不是所有模块的日志都需要调整至debug层级的，甚至trace层级的。 所以，参数设置总文件可以一个参数调整所需的几个模块的层级调整。这个需要业务的知识，和业务人员讨论那些重要功能牵涉到哪些模块。

日志等级文件一般在每个模块中都有设置，但要有一个总开关，一个总配置文件。它的优先级要比模块的参数优先级高。

2. 在线和离线

不是所有的调试都需要在线的，测试的时候，可以离线的。运维的时候，基本上都是在线的。但有时针对某个问题，可以在线收集完日志，离线上传到日志工具上再分析。 

在线采集日志的时候，ELK应该加缓冲工具，比如kafka 队列。 因为出错的时候，日志特别多，所以，没有缓冲工具，日志采集这块容易掉线。商业工具应该内置有缓冲组件。

3. 项目管理

在大公司里，比如300个开发人员以上的公司，可以有专门的日志组，采用saas模式为各个项目组服务，一个团队支持多个项目，属于公司项目管理团队的事。日志其实也是专业性强的技术，比如搭建ELK的在线系统，从头入手，还是有学习曲线的。 懂日志的人不断提高业务水平，可以更有效的保证业务应用的高稳定性，搞业务的人懂日志的功能，潜能，内部机制，可以让日志人员开发自己所需的功能。通过日志，使运维，开发，调试事半功倍。

4. 技术选型

一般的目标单键值追踪是很简单的，但有些目标有多个键值，怎样跟踪呢？目前的日志工具，ELK，日志易和splunk都是基于硬盘的，跟踪多键值目标效率很低。 那后台就要换内存数据库，newSQL 来做日志分析工具。这时候，日志工具基本上都是定制的。但这种情况，要尽量避免。现成的工具，哪怕是商业的，总是在成本上占有优势。  

版本：

本博客初写于2023年1月24日周二，上海。