2018-11-11

关于日志的思考

关于打印日志，其实有很多讲究，好的日志让人一目了然，能够得到非常多的有用信息，也能帮助运维人员找到问题。那么这篇文章尝试对日志打印做一些总结。

为什么需要有日志

在打印日志之前，我们一定要先明确输出日志的目的，我们的日志是给谁看的，日志需要包含什么信息。日志一方面是给人看的，另一方面也是给程序分析的。站在系统运维人员的角度来看，我们希望从日志能够得知程序的监控状态，当程序"假死"的时候，如果有输出日志，我们知道程序在后台计算中，如果没有日志输出，可能会被误认为是程序奔溃了，导致程序被强制退出。系统出错了，我们希望能够看到错误原因，比如获保存数据事变，日志应该提供对应的诊断信息：没有可用存储空间，文件权限不够等等。总的说来，我们打印日志的目的可以归纳为以下几点：

• 体现程序状态
• 记录操作历史
• 展示调试诊断信息
• 统计操作行为

日志级别

日志级别非常重要，因为不同的日志级别，输出的日志内容不一样，低级别的日志会输出太多的诊断信息，同时也会增加系统的io压力，日志文件占用大量的磁盘空间。尽量不要在生产环境使用debug,trace这样的日志级别，输出了太多的无用信息，增加了系统的负担。生产环境的日志级别推荐使用info,warn级别日志输出。测试环境应该使用debug或者trace级别，它能发下许多系统问题。你不应该忽视warn级别的日志，除非你真的知道了发生了什么。

日志内容

日志应该包那些内容呢

• info 级别的日志应该展示的是系统行为或者用户行为
• error 级别的日志应该是在程序发生错误的时候输出，它一定要包含错误的上下文信息
• debug 级别应该包含系统行为和用户行为的详细信息，最好是是运维发现程序不正常，打开debug日志能够发现问题所在，他应该是级别的开发人员，或者系统运维人员看的。
• trace 级别的日志应该是所有的日志信息，包含应用本身，以及依赖框架或者依赖库本身的诊断信息，如果是http请求，那么他应该尽可能的包含一个完整的请求的所有信息。

日志信息安全

因为系统开发人员无法决定系统会被部署在怎样的环境，也不能确系统日志会被那些人员看到：也许是一个hacker，也许是另一个工程师。所以为了安全，日志里面不应该包含了用户密码，银行卡账号等非常隐私的信息，任何级别的日志都应该遵守这个约定，因为开发人员也无法确定系统会以怎么的日志级别被部署。

日志内容结构

文章开头部署我们就介绍过了，我们的日志是给人和程序看的，给人看的日志很简单，只要语义明确即可。但是，这样的日志往往利于程序分析，所以我们在输出日志的时候，必须要要求日志有规律，有格式，便于程序解析分析。比如说：json格式。

日志文件特性

我们的日志会被程序检索，被人打开阅读，所以单个日志的文件最好不要太多，大文件对于编辑器打开阅读来说非常不要。日志应该按照日志或者按照文件大小来进行分割。一直文件应该能够直观的体现日期，当我要查找的日志的时候，我一眼就明白应该从那个日志文件里面寻找，而不是翻遍所有的人日志的文件。日志文件最好也应该区分日志级别，比如:2018-11-10.error.log这样的日志文件，只需要打开这个日志文件，就知道这天系统发生了什么错误，发生了多少次。之前说过了日志文件会占用大量的磁盘空间，如果你想每次都手动删除日志，来保证系统有足够的磁盘空间来维持运行，那么你的日志就应该设置保存期限，过期日志自动删除，而不是堆积如山。如果你想保存更多的时间，那么你应该收集这些日志到一个有更大磁盘的空间的系统，这个系统可能是一个网络云盘之类的东西。