对日志规范的思考

概述

      系统上线之后，一旦发生异常，第一件事就是要弄清楚当时发生了什么，用户当时做了什么操作，环境有无影响，数据有什么变化，是不是反复发生等，然后再进一步的确定大致是哪个方面的问题。这时，日志就给我们提供了第一手的资料。

基本原则

● 不影响系统正常运行；

● 不允许产生安全问题；

● 不允许输出机密信息；

● 日志可供开发人员定位问题的真正原因；

● 日志可供监控系统自动监控与分析；

日志级别

       ERROR：系统发生了错误事件，但仍然不影响系统的继续运行。系统需要将错误或异常细节记录ERROR日志中，方便后续人工回溯解决。

       WARN：系统在业务处理时触发了异常流程，但系统可恢复到正常态，下一次业务可以正常执行。如程序调用了一个旧版本的接口，可选参数不合法，非业务预期的状态但仍可继续处理等

       INFO：记录系统关键信息，旨在保留系统正常工作期间关键运行指标，开发人员可以将初始化系统配置、业务状态变化信息，或者用户业务流程中的核心处理记录到INFO日志中，方便日常运维工作以及错误回溯时上下文场景复现

      DEBUG：可以将各类详细信息记录到DEBUG里，起到调试的作用，包括参数信息，调试细节信息，返回值信息等等。

      TRACE：更详细的跟踪信息。

       上述日志级别从高到低排列，是开发中最常用的五种。生产系统一般只打印INFO 级别以上的日志，对于 DEBUG 级别的日志，只在测试环境中打印。打印错误日志时，需要区分是业务异常(如:用户名不能为空)还是系统异常(如:调用 会员核心异常)，业务异常使用 warn 级别记录，系统异常使用 error 记录。