日志系统的使用

一、日志在项目中的作用

Log 日志，主要用于记录程序运行的情况，以便于程序在部署之后的排错调试等，也有利于将这些信息进行持久化（如果不将日志信息保存到文件或数据库，则信息便会丢失）。

1.1 查看程序当前运行状态

如果想了解程序当前的运行情况，我们通过实时查看应用日志的输出，就能进行分析。比如，你在浏览器里输入一个 action 地址，该 url 负责执行一些批量处理，action 运行后，假设处理比较耗时，你再浏览器里无法直接看到程序的执行结果，此时，你可以打开系统日志，通过从日志输出信息就能轻松地分析该 url 的执行情况。

1.2 查看程序历史运行轨迹

如果想了解历时程序的运行情况，我们通过查看应用历时日志的输出，就能进行分析。比如，你想了解下上周周末用户访问量，你可以打开系统上周周末的日志记录，进行分析。你想了解昨天的某个定时任务是否正常执行，你可以打开昨天的系统日志，精确查找该定时任务的输出信息，从而判断定时任务是否执行。

1.3 排查系统问题

排查系统问题是程序员最熟悉的味道了，在项目维护过程中，出了任何问题，都需要程序员去进行排查。此时，如果没有清楚明了的日志记录，想要核查出问题的原因，难于上青天。

一个优秀的程序员一定是个日志记录高手，如果日志记录的好，处理得当，排查问题则易如反掌。

大家有没有遇到一种场景，一个问题发生了，有的人能迅速定位问题并解决，有的人搞了半天，还没发现问题的产生原因。

其实快速定位问题的人一定记录了详细的日志，因此当问题发生的时候，通过核查问题发生时候的日志，就能快速的找出问题产生的原因。

1.4 优化系统性能

通过记录程序运行的时间，就能判断程序从执行开始到执行结束消耗的时间，从而判断系统性能是否达标，为系统性能优化提供判断依据。

1.5 安全审计的基石

网络安全越来越受到大家的关注，所以系统安全目前是项目过程非常重要的一个环节，安全审计也是系统中非常重要的部分。

通过系统日志分析，可以判断一些非法攻击，非法调用，以及系统处理过程中的安全隐患。

比如，大家平时都在做运营系统，其中运营人员在通过界面处理一些数据的时候，如果没有清楚的日志操作记录，一条数据被删除或者修改，你是无法找到是谁操作的，但是如果你做了相应的记录，该数据被谁删除或者修改就会一目了然。

通过以上 5 点说明了日志在项目维护过程中的重要作用。一个系统是否容易维护，很大程度上是基于程序员在程序开发过程中的代码日志是怎么记录的。日志记录的越清楚，维护起来就越容易，有的程序员没有日志记录意识，或者对日志记录认识不清，或者是不知道日志该如何记录，这势必会给项目后期的维护带来一个个大坑。

当项目经理让你解决一个线上问题的时候，正好遇到了一个没有日志记录习惯的人写的代码，你就能体会到那种痛苦，不由地想要爆粗口。

因此，作为一个程序员来说，掌握代码日志的记录方法，是程序员生涯的一项基本功。写代码时做好日志记录是 “即利人又利己” 的做法，不写日志记录就是 “损人不利己” 的做法。

二、日志的内容设计

日志的内容就是，软件应该在什么地方？使用什么等级？输出什么信息？看似简单，里面却有大学问。我看过输出信息一团乱麻、零碎混乱的日志，也看到过逻辑清晰、工整条理的日志。好的日志文件令人神清气爽，事半功倍；差的日志文件则是雪上加霜、火上浇油，要人命！可见，想做好并不简单！

2.1 谁在使用日志

有一个问题，可能很多开发人员并没有认真思考过，就是日志到底是给谁用的？使用软件的人（客户），运维人员，软件开发人员，当然，答案是全部。

不同的角色，有不同的视角，在不同的阶段，有不同的需求，那么日志就应该提供不同的帮助。在做日志模块的内容设计时，也应该站在不同的角度去考虑，要思维清晰，哪些信息给客户看，哪些给运维人员看，哪些给程序开发人员看。要讲究轻重主次，不是说详细就一定好，给客户看函数调用过程的信息有意义吗？

2.2 日志的等级设置

开发过一些系统，大体的感受是这样的：刚开始的时候，大家都相对比较讲究，日志的等级、内容、位置都会去思考、选择。但是随着时间不断的延伸，功能不断的扩展，日志逐渐变的混乱，最终沦落为乱麻一片！

日志通常有多个等级，等级并不单单指 “详细程度”，还关系到适用场景，服务对象，目的功能等。

• ERROR: 准确！Matter life or death!
  是错误信息 —— 包括错误的类型，错误的内容，位置和场景，是否可恢复，等等。只有当错误会影响到系统的正常运行时，才应该作为错误日志输出；就好像是医院体检后，确诊了，就是 HIV 阳性，铁定没跑了，自求多福吧，做决定吧！这才是 “错误” 的意思。

• WARN: 提个醒
  是提醒信息，要留心，要关注，只是目前还正常。私生活太糜烂了，提醒你一下，自己反省反省，再任性下去后果自负哦！

• INFO: 简洁！Who? When? Where? Do 了 what？
  系统的基本运行过程，运行状态，每逢大事 mark 一下，捡重要的、关键的记，别太唠叨，老板们很忙没工夫认真看！

• DEBUG: 详细！Details of process！
  系统运行过程与状态的细节信息，可用于调试。类似于警察审讯嫌疑犯，从昨天晚上八点到今天早上十点半，老实交代，每分钟都说说清楚了；DEBUG 的目的就是要破案！

• TRACE: 细致入微！Details of structure and content！
  系统结构与内容的细节信息，这个就更详细了，比如一些关键对象的内容，函数调用参数、结果，等等吧！就是要给软件拍个片，五脏六腑，七经八脉，都 dump 出来看看；不光要审讯，还要验血，验指纹，验 DNA！

这里把日志系统跟业务跟踪系统分开了，但是有时候，当系统规模不大时，日志系统也会承担起业务跟踪、业务分析，甚至资源统计的功能！

2.3 日志使用的几种场景

1. 开发过程中：
   日志是一种友好、强大的记录软件运行时内部结构和状态的工具，是调试利器，当然每种语言都会提供专门的调试工具，比如 c/c++ gdb，java 的 jdb 等等。但是涉及到业务逻辑，并发，交互等情况时，还是日志更轻巧、便捷！我一般是在对 “陌生” 代码（比如开源软件）学习时，才会用 gdb 等调试工具，强大但笨重，更适合梳理代码结构，而不是功能或业务结构！

2. 测试过程中：
   在进行功能测试时，通过 debug 或 trace 信息，就像看监控回放一样，让犯罪分子无处遁行！

3. 软件学习时：
   学习软件时，包括软件的架构设计、业务功能、代码逻辑，日志总能提供很多线索、很多帮助。记得很久以前，看某个开源系统的代码，部署完以后，直接打开 trace 跑一边，系统的整体结构及内容，一目了然，再结合设计文档，很快就没明白了！就那一刻，让我深刻的记住，好的日志系统，原来是这么的神奇啊！

4. 正常运行：
   一定不要开着 debug 跑系统，没有意义！前提是，ERROR 信息要准确、规范，客户只关系生死问题，再多的信息对他们也没有意义！