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

日志作为业务应用程序的必不可少的一部分，我们有没有充分利用起来呢？比如，协调一致的格式，脱敏，埋信息点，利用日志跟踪。同时，也要留意到，大量的日志如果写到磁盘时，它对于毫秒级的应用是不可承受的慢。

前言：

对于日志，一句话就是您想要解决什么问题，就要设计怎么样的日志，以便于您解决问题。如果你是架构师，你就是设计师。

问题陈述：

对于目前的很多架构师来说，先是遇到很多问题：

1. 开发队伍不是一个，很难协调日志格式。

2. 旧的程序包已经有旧的日志格式，全部更新代价太大。

3. 日志到底能解决什么问题，架构师自己也不明确。怎么设计日志格式呢？

4. 技术选型，我到底是用现成的日志工具ELK，还是日志易或splunk，还是定制化一套自己的日志应用程序呢？

。。。

问题阐述：

对于第一个问题：格式无法统一

开发队伍不是一个，这是项目执行问题，架构师是否可以规定如果打下日志，必须用规定的日志API，可以在log4j，logback再包一层，而不是每个开发队伍，或每个开发人员各用各的方法。如果谁违反，可能有什么小惩罚，如果今天做得好，可以有什么积分。笔者也遇到，国内的开发队伍往往面对开发时间短，项目管理无法监管的问题，那日志格式就无法统一，日志所产生的作用就没有了。

对于第二个问题，历史遗留

是预算的问题。先前的日志可能格式怪异，信息缺少。。。 对于格式怪异，会造成日志解析的困难，直接造成技术上的难度。 信息缺少，那就只有后加上，就是纯预算问题。一个历史沉淀多年的组件，非常多代码的软件包，要加信息，预算怎么解决？！

第一，第二个问题大部分工作是项目经理的工作和头痛的事。我们来分析第三个，和第四个问题。因为这是原汁原味的架构师问题。

对于第三个问题，日志功能

日志能解决的问题很多，以下为几个类别：

功能：

性能和稳定性测试：

笔者在芬兰诺基亚工作的时候，用日志解决稳定性测试，性能测试的问题。技术人员都知道，逻辑上的错误，一般都能重复再现。但性能上的问题，稳定性方面的问题，要捕捉重现问题难度就很大，因为性能，稳定性问题一般不重现，只有当特定时候，才可以复制。其实，读到这里，读者可以知道，日志对多线程应用特别有帮助。单线程，有的都可以用单步调试看问题。多线程，特别是性能，稳定性测试，多线程交织在一起，有的无法解藕的，没有办法用一般工具的。只能用日志来排查问题。 

KPI报告：

有的程序，都会向数据库输出指标，比如时序数据库，有的应用，开发人员就把KPI打入日志，然后让日志应用工具，比如 Elastic Search，Solr，Splunk 直接用现成工具库，描绘成不同的图线，报表。

目标跟踪，

比如用户跟踪，事务（transaction）跟踪，订单跟踪，回放。在通讯领域中，用户的手机信号怎么会断掉的？是用户自身问题，还是网络问题？事务失败，是那个模块出现问题？其实这些信息，可以作为数据挖掘的非常有价值的数据。

告警

模块的消息进出不一致，

各个模块的消息进出应该是匹配的，日志统计完以后，如果不匹配，可以通过日志应用程序告警。

内部堆栈

在Java应用程序中，JVM的一些参数，可以每隔一段时间打印在日志里，然后让日志应用程序决定目前业务应用程序是否健康。如果不健康，输出告警。

这一类要注意的问题：

脱敏数据，

敏感数据要上mask。

日志动态改变模式，

在生产线上，我们都是用log.error 这个层次，以免影响产品的性能，但在特定时候，特殊时段，我们在线调试的时候，我们要看debug层次的信息，甚至要看trace层次的信息，所以，日志的层次改变是动态在线改变。打出一段日志后，再恢复成平时的error 层次。

对于第四个问题，技术选型

一般项目，20个人左右，甚至100个人左右的项目，尽量用现成工具，那怕是商业工具，比如ELK，日志易，splunk。对于多线程，业务复杂度高，需要跟踪，又没有单一键值的 （key），或者说项目投资是1个亿以上的，还是要自己定制一套日志系统。 哪怕是这样，也是业务代码和工具结合着用，重新打造一个底层的优化的索引引擎是不现实的。有的功能是现有工具无法实现的。ELK多重join无法实现，日志易，Splunk在动态回溯，单一目标多键值跟踪上也有做不到的地方。未来都会一，一展开。

版本：

1. 第一部分第一版写于2013年1月19日上海。发布于CSDN。