前言
在程序中打错误日志的目的是为了排查问题和解决问题提供重要的线索和指导，在测试环境我们可以debug，但是生产问题无法如此调查。在实际中打的错误日志内容和格式变化多样，错误提示上可能残缺不全、没有相关背景、不明其义，使得排查解决问题成为非常不方便或者耗时的操作。
日志功能
- 监控告警
- 记录行为轨迹
- 快速定位问题
日志实效性规约
- 当天日志命名，以"应用名.log" 来保存
- 过往日志命名，以{log name}.log.{保存日期} 命名：日期格式 yyyy-MM-dd
- 日志文件至少保留 15 天，便于排查某些以周期为频次发生的异常
- 敏感操作信息联机存储 6个月，网络安全相关法律规定（使用warn级别）
日志记录规约
- 系统应依赖使用日志框架（SLF4J、JCL）的 API而不是具体日志库中的
- 在日志输出时，字符串变量之间的拼接使用占位符的方式
- 日志打印时禁止直接用 JSON 工具将对象转换成 String
- 尽量用英文来描述日志错误信息
日志输出规约
- 日志级别开关判断 对于 trace/debug/info 级别的日志输出，必须进 行日志级别的开关判断
- 异常日志信息要完整 异常日志信息应该包括 以下两类信息： 案发现场信息 异常堆栈信息
- 避免重复打印日志 重复打印日志，浪费磁 盘空间，务必在日志配 置文件中设置 additivity=false
打错误日志的基本原则：
1、尽可能完整。每一条错误日志都完整描述了：什么场景下发生了什么错误，什么原因（或者哪些可能原因），如何解决或提示（是什么？为什么？怎么做？）
2、尽可能具体。比如NC 资源不足，究竟具体指什么资源不足，是否可以通过程序直接指明；通用错误，比如 vm not exist ，要指明在什么场景下发生的，可能便于后续统计的工作
3、尽可能直接。最理想的错误日志应该让人在第一直觉下能够知道是什么原因导致的，该怎么去解决，而不是还要通过若干步骤去查找真正的原因
4、将已有经验集成直接到系统中。所有已经解决过的问题及经验都要尽可能以友好的方式集成到系统中，给新进人员更好的提示，而不是埋藏在其他地方
5、排版要整洁有序，格式统一化规范化，密密麻麻、随笔式的日志看着就揪心，相当不友好，也不便排查问题
6、采用多个关键字唯一标识请求，突出显示关键字：时间、实体标识（比如vmname）、操作名称
扩展日志的设计与规约
- 扩展日志单独存储 应用中的扩展日志（如打点、临时 监控、访问日志等）单独存储错误日志单独存储 业务日志与错误日志分开存储
错误码规约
错误码的功用
方便系统与系统、人与人、人与系统之间的沟通
错误码规约
- 定义时要有字母也要有数字
- 要分级分类管理
- 不能直接输出给用户作为 提示信息使用
- 不要与业务架构或者组织架构挂钩
- 使用者避免随意定义新的错误码
- 便于不同语言的开发者之间协作
示例：
如果结果并非所愿，那就在尘埃落定前奋力一搏！ --《夏目友人帐》
参考文献：Joel老师的ppt