目录

日志记录原则

  • 日志中不要记录无用信息,防止无用日志淹没重要信息
  • 要明确不同日志的用途,对日志内容进行分类
  • 日志信息要准确全面,努力做到仅凭日志就可以定位问题
  • 日志格式要统一规范
  • 日志要不断优化、完善

日志级别

参考:monolog/01-usage.md

Monolog 支持 RFC 5424 描述的日志级别:

  • DEBUG (100): 详细的调试信息

  • INFO (200): 一些重要的敏感的运行时数据日志、sql日志等

  • NOTICE (250): 一些重要的,但可能需要做提示的事件

  • WARNING (300): 在程序预期的逻辑错误并非运行时错误,比如重复请求、鉴权失败、数据缺失等

  • ERROR (400): 运行时错误,一般是非预期的异常错误,不要求马上处理的错误,但又重要,需要定期排查分析。

  • CRITICAL (500): 这个比起error更严重,比如应用的sms、push、queue等服务不可用了

  • ALERT (550): 这个级别,一般是应用服务、数据存储服务等架构级别的服务异常,这个一般需要马上预警,并处理(自动重启或手动处理)。

  • EMERGENCY (600): 服务不可用了,比如最近羊了个羊突然火爆,一天宕机3次,整个服务不可用。

Emergency

  • 导致系统不可用的事故,属于最严重的日志级别,完全不可用。
  • 我们觉得基本不会等到这个等级,有模块服务出现中断,我们就会处理。

Alert

  • 必须马上处理的问题,紧急程度低于 Emergency
  • Alert 错误发生时,已经影响了用户的正常访问
  • 与 Emergency 的区别是,Alert 下系统仍然可以部分使用。例如:DB / Cache 无法连接。

Critical/Fatal

  • 紧急情况,组件或小服务不可用,需要及时修复。例如:推送服务失败。
  • 影响功能闭环

Error

  • 运行时出现的错误,不必要立即进行修复
  • 错误不影响整个逻辑的运行,但需要记录并做检测。
  • 比如说没有执行预期的分支

Warning

  • 可能影响系统功能,需要提醒的重要事件
  • 比如超过阈值、配额快超额、输入存在安全隐患但已经处理、执行了不再允许的代码块
  • 对于 Warining 级别的日志,虽然不需要马上处理,但也需要及时查看并预期处理

Notice

  • 不影响正常功能,但需要注意的消息
  • 执行过程中较 Infomational 级别更为重要的信息。
  • 可以理解为提醒,意味着程序调用了外部或是执行一些我们认为比较少见的分支代码

Infomational

  • 用于记录系统正常运行情况下的一般信息,强调应用程序的运行过程。例如:某个子模块的初始化、某个请求的成功执行等
  • 通过查看 Infomational 级别的日志,可以很快对系统中出现的 0~5 级别的错误进行定位

Debug

帮助开发、测试、运维人员对系统进行诊断的信息。

推荐日志等级

8个日志等级区分度太小,实际开发过程中,可以根据实际情况,我们可以压缩等级,拉大区分度,比如我们可以使用5个等级:

  • fatal 严重错误,比如模块功能服务失效,一般就是服务挂了
  • error 一般错误,需要及时解决的,比如异常错误导致接口请求失败,一般是系统/语言/服务的错误或异常
  • warning 警告,需要及时注意甚至及时解决的,比如超过阈值问题,更多属于人为逻辑判断日志
  • info 重要信息,一般用于事后排查问题时,了解当时重要逻辑执行过程,比如一些定期处理的重要步骤记录、支付退款等重要环节的重要过程记录,一般也用于debug
  • debug 开发阶段,为了更好调试和排查bug,补充更多变量、分支走向信息的记录

日志格式规范

  • 统一字段命名
  • 统一字段风格
  • 统一日志层级风格
  • 统一字段顺序
  • 每个请求需要加入请求 ID

日志中记录什么

建议记录的日志内容

  • 在系统启动或初始化时记录重要的系统初始化参数
  • 记录系统运行过程中的所有的错误
  • 记录系统运行过程中的所有的警告
  • 在持久化数据修改时记录修改前和修改后的值
  • 记录系统各主要模块之间的请求和响应
  • 重要的状态变化
  • 系统中一些定期执行的任务的执行进度

不建议记录的日志内容

  • 文件内容或者一大段消息的内容:如果实在需要记录,则可以截取其中一些重要的信息来记入日志
  • “良性”错误:有时候虽然出现了错误,但错误处理的流程可以正确解决这种情况,例如某个数据为空,但我们可以通过其他方式获取并补充时,尽管是个错误,但错误处理流程可以弥补时,我们觉得不需要做error级别的记录,但可以是debug下的记录,如果这个数据为空是一个正常用户不可能发生的,但却发生了,可以warning可以提醒我们排查输入端可能存在潜在的问题

参考