日志打印规范

主要级别划分
严重等级排序：  TRACE < DEBUG < INFO < WARN < ERROR

ERROR    表示应用系统出现异常或故障，需要预警并及时解决，否则该功能将无法正常运行并提供服务能力。
WARN    表示应用系统出现不符合预期的现象，但服务并未受损，可根据实际情况选择性预警，解决时效要求不高，但需要额外关注。
INFO    表示用于记录系统运行过程或重要信息点，主要为故障定位、过程追溯、数据分析等提供辅助能力。
DEBUG    表示用于在测试或本地的非生产环境中使用，主要为了方便开发调试程序，而在生产环境中禁止使用
TRACE    特别详细的服务调用流程各个节点信息。业务代码中，除非涉及到多级服务的调用，否则不要使用

日志打印的基本规范

对程序运行情况能够进行记录和监控,在必要时可详细了解程序内部的运行状态
在必要时可详细了解程序内部的运行状态
对系统性能的影响尽量小（代码中打印方式、打印的日志量与日志存储等方面.
禁止在代码循环体中直接打印非DEBUG级别的日志
每条日志在语义上可独立被理解，减少上下文关联理解
禁止在日志中打印敏感数据，如用户账户余额，密码等(注意: md5,base64不是加密算法，是可逆向，sha128现在也只要很低的硬件经过10小时左右就能破解，所以也不要用简单的加密计算后打印 )

在哪些场景下必须打日志呢？

系统初始化流程，包括各依赖库的加载/初始化
编程语言提示异常
业务流程预期不符
系统核心角色，组件关键动作:  有版本更新，升级模块, 账户的登录，退登信息,关键事件/业务打印
作为服务提供方，要打印入参、出参.
定时任务运行相关记录

各个级别日志打印举例

ERROR事件: 影响到程序正常运行、当前请求正常运行的异常情况

1.打开配置文件失败

2.所有第三方对接的异常(包括第三方返回错误码)

3.所有影响功能使用的异常，包括:SQLException 、以及业务异常之外的所有异常

4.内存申请失败,空指针异常

WARN  不应该出现但是不影响程序、当前请求正常运行的异常情况

但是一旦出现了也需要关注，因此一般该级别的日志达到一定的阈值之后，就得提示给用户或者需要关注的人了。如：

1.有容错机制的时候出现的错误情况

2.文件IO错误，如找不到配置文件，但是系统能自动创建配置文件

3.即将接近临界值的时候，如 cpu 存储已经超过阈值的 80%，就需要打印 warn 级别的日志

网络请求，文件IO，数据解析错误

4. 参数&参数解析错误
5. 业务逻辑错误，业务逻辑中不常走到的分支，如switch/if...else if...的结果没有匹配到 

INFO  记录输入输出、程序关键节点等必要信息, 出问题时可根据INFO日志诊断出问题

1.Service方法中对于系统/业务状态的变更

2.调用第三方时的调用参数和调用结果（入参和出参.

3.提供方，需要记录入参

4.定时任务的开始执行与结束执行
5.各个模块初始化的函数入口，结果要打印到日志上 
 

DEBUG  调试信息，开发调试时打印的数据，方便解bug