日志实践---日志该如何打印？

写在前面的话

在过去的两年里，一直在做日志类工具，期间对日志该如何打印思考不少，下面就结合自己的理解与实践尝试着讲讲这个话题。
首先，我们来看下日志的用途及意义，大致包括：

1. 通过日志检索、关键字及业务指标监控，实现更快的问题发现及定位；
2. 通过对日志数据的统计分析或深度挖掘，帮助更好的运营及决策；
3. 从安全审计角度，有助于实现网络安全及审计工作。

为了更好地发挥日志的价值及意义，我们还需要考虑日志打印的性能及影响，实现对日志更快地打印和更好地管理。

接下来讲的所有规则、建议及方法的总结都会围绕上面四个维度展开：
运维与监控、运营与决策、安全审计、性能与影响

从不同的视角出发，我们往往会有一些不同的认识。不同的人，关注的维度也不一样。

• 从开发者的角度：更多的会关注我的日志如何打印，性能会比较好、对服务影响最小、对后面程序的拓展性最好、有助于定位问题。
• 从运维者的角度：更多的会关注打印出的日志能否暴露服务的问题，能否快速定位现网问题，能否实现有效的监控及告警，最怕一大堆无用日志淹没了有用日志，日志打印不合规，没法进行有效监控。
• 从运营者或者领导层的角度：关注的是业务相关的日志，通过这些日志能否分析出对市场和产品决策有帮助的信息，能否真实反映出一些有价值的用户行为数据，是否打印出了产品运营所需要的信息，能否产生商业价值。
• 从安全审计的角度：更多的会关注打印的日志是否符合公司及国家相关的规定，能否实现安全审计的需求，能否有效防止安全事故的发生。
• 从日志平台创建者的角度：希望满足各方面人员的需求，最大程度地实现日志的价值，体现日志平台的意义。

下面我们一起来看看关于日志打印方面一些主流的规则或建议或方法（PS:其中涉及的一些具体事例，语言为java）。

运维与监控

【严格遵守团队或者公司关于日志级别之间的约定，不要凭感觉定级别，尤其ERROR级别的日志，不要随意打印。另外需要思考下，具体打印什么会比较有利于后期的运维监控】

  从运维与监控的角度，能否根据日志级别就判断出问题的等级，能否使用相关工具（如：zabbix、splunk、ELK等）配置日志关键字告警，对自己特别关注的业务能否做出单独的监控，问题定位时，利用日志相关工具能否根据相关的关键字快速找到问题，对于事务类型的，能否根据某个事务ID将一个事务相关的日志串在一起查看等等，这些都是我们需要考虑的问题。

  关于日志级别，比较常见的有：TRACE, DEBUG, INFO, WARN, ERROR, FATAL。不过，在实际中用的比较多的还是DEBUG, INFO, WARN, ERROR这几个，可以采用这4种类别去定义不同的事件。团队或者公司可以针对不同的级别定义相关的规则，哪些操作场景中，需要打印日志，分别打印什么级别的日志，要有一个明确的约定。

  我见过生产环境每天一直在打印ERROR日志，服务却没什么问题的情况。有些团队根本不重视日志打印，生产环境中服务日志随意打印。这样是很不利于运维与监控的，如果日志中不打印方便定位的有效日志，服务出问题后就很难通过日志来快速定位问题。如果日志中打印了太多不影响服务的ERROR日志，那么通过日志将没法进行有效监控。比如常见的日志关键字监控场景对于这种日志就没有任何监控意义。

  对于ERROR和WARN级别，如果拿不准时，我觉得可以参考StackOverFlow上的一个说法： “如果你希望系统管理者深夜从床上爬起来处理的问题，就可以记录为ERROR级别日志，如果不是，那就设为WARN级别”。

关于日志级别的约定，我觉得可以参考：

日志级别	说明
DEBUG	主要记录调试信息，跟踪函数的进入或退出等，记录当前调用的函数名、参数、内部变量值、返回值等信息，方便开发人员调试一些较复杂的、比较容易出问题的地方。其他等级不方便记录的信息，可以通过DEBUG来记录。
INFO	主要保留系统正常工作时的一些关键运行指标，一些状态信息如数据库容量等，一些用户业务流程中的核心处理记录，方便问题回溯时上下文场景的复现，某些子系统的初始化，某些请求的成功执行等。INFO级别的日志也要适量，不宜太多。
WARN	业务处理时，触发了异常流程，但是不影响整个系统的运行。系统状态或者用户输入和预期不一样，对于一些级别上还达不到ERROR级别的，可以考虑WARN级别。
ERROR	高级别错误，系统已经出现了严重的问题，已经影响了用户的正常访问，无法自动恢复到正常状态，需要马上进行人工介入和处理的。

对于每一条日志的打印，需要思考其合理的日志等级，尤其是ERROR级别的日志，一定要想清楚是否是合理的。

另外，非ERROR级别的日志中，尽量不要出现类似error、fault、fail、exception等敏感词汇，合理的日志等级选择，才能发挥日志关键字监控的作用。并且，日志最终一般都会采集到相关的日志平台进行集中检索和统计分析，合理的日志，才能更好地发挥出日志检索的意义，帮助快速定位到问题。

对于日志级别的思考，还可以参考阿里JAVA规范中如下两条：
【推荐】谨慎地记录日志。生产环境禁止输出debug日志；有选择地输出info日志；如果使用warn来记录刚上线时的业务行为信息，一定要注意日志输出量的问题，避免把服务器磁盘撑爆，并记得及时删除这些观察日志。
说明：大量地输出无效日志，不利于系统性能提升，也不利于快速定位错误点。记录日志时请思考：这些日志真的有人看吗？看到这条日志你能做什么？能不能给问题排查带来好处？

【参考】可以使用warn日志级别来记录用户输入参数错误的情况，避免用户投诉时，无所适从。注意日志输出的级别，error级别只记录系统逻辑出错、异常、或者重要的错误信息。如非必要，请不要在此场景打出error级别。

运营与决策

【请将用于问题定位、业务分析和安全审计的日志分开打印，用于业务分析的日志最好使用json格式，并根据不同的业务场景定义便于业务统计分析的字段】

1. 从日志滚动策略和保存策略角度：用于问题定位、业务分析和安全审计的日志量以及需要保留的时长都是不一样的，所以它们的滚动策略和保存策略也应该是不一样的，最好分不同的文件打印，使用不同的管理策略。