日志记录规范
日志级别
一个项目各个log级别的定义应该是清楚明确的，是每个开发人员所遵循的； 即使是TRACE或者DEBUG级别的日志，也应该有一定的规范，要保证除了开发人员自己以外，包括测试人员和运维人员都可以方便地通过日志定位问题； 对于日志级别的分类，有以下参考：
- FATAL — 表示需要立即被处理的系统级错误。当该错误发生时，表示服务已经出现了某种程度的不可用，系统管理员需要立即介入。这属于最严重的日志级别，因此该日志级 别必须慎用，如果这种级别的日志经常出现，则该日志也失去了意义。通常情况下，一个进程的生命周期中应该只记录一次FATAL级别的日志，即该进程遇到无 法恢复的错误而退出时。当然，如果某个系统的子系统遇到了不可恢复的错误，那该子系统的调用方也可以记入FATAL级别日志，以便通过日志报警提醒系统管 理员修复；
- ERROR — 该级别的错误也需要马上被处理，但是紧急程度要低于FATAL级别。当ERROR错误发生时，已经影响了用户的正常访问。从该意义上来说，实际上 ERROR错误和FATAL错误对用户的影响是相当的。FATAL相当于服务已经挂了，而ERROR相当于好死不如赖活着，然而活着却无法提供正常的服 务，只能不断地打印ERROR日志。特别需要注意的是，ERROR和FATAL都属于服务器自己的异常，是需要马上得到人工介入并处理的。而对于用户自己 操作不当，如请求参数错误等等，是绝对不应该记为ERROR日志的；
- WARN — 该日志表示系统可能出现问题，也可能没有，这种情况如网络的波动等。对于那些目前还不是错误，然而不及时处理也会变为错误的情况，也可以记为WARN日 志，例如一个存储系统的磁盘使用量超过阀值，或者系统中某个用户的存储配额快用完等等。对于WARN级别的日志，虽然不需要系统管理员马上处理，也是需要 即使查看并处理的。因此此种级别的日志也不应太多，能不打WARN级别的日志，就尽量不要打；
- INFO — 该种日志记录系统的正常运行状态，例如某个子系统的初始化，某个请求的成功执行等等。通过查看INFO级别的日志，可以很快地对系统中出现的 WARN,ERROR,FATAL错误进行定位。INFO日志不宜过多，通常情况下，INFO级别的日志应该不大于TRACE日志的10%；
- DEBUG or TRACE — 这两种日志具体的规范应该由项目组自己定义，该级别日志的主要作用是对系统每一步的运行状态进行精确的记录。通过该种日志，可以查看某一个操作每一步的执 行过程，可以准确定位是何种操作，何种参数，何种顺序导致了某种错误的发生。可以保证在不重现错误的情况下，也可以通过DEBUG（或TRACE）级别的 日志对问题进行诊断。需要注意的是，DEBUG日志也需要规范日志格式，应该保证除了记录日志的开发人员自己外，其他的如运维，测试人员等也可以通过 DEBUG（或TRACE）日志来定位问题；
日志分类
日志从功能来说，可分为诊断日志、统计日志、审计日志。
诊断日志， 典型的有：
请求入口和出口 外部服务调用和返回 资源消耗操作: 打开文件等 容错行为： 譬如云硬盘的副本修复操作 程序异常： 譬如数据库无法连接 后台操作：清理程序 启动、关闭、配置加载 抛出异常时，不记录日志
统计日志：
用户访问统计 计费日志（如记录用户使用的网络资源或磁盘占用，格式较为严格，便于统计）
审计日志：
管理操作 将不同需求的日志记入到不同的日志文件中，可以方便相关问题（管理平台操作审计，用户操作计费等）的处理。针对每一种需求，需要对日志的格式，日志记录的内容等进行特别的记录。
记录日志
需要在日志中记录的内容有：
在系统启动或初始化时记录重要的系统初始化参数 记录系统运行过程中的所有的错误 记录系统运行过程中的所有的警告 在持久化数据修改时记录修改前和修改后的值 记录系统各主要模块之间的请求和响应 重要的状态变化（如用户咨询状态改变等） 系统中一些长期执行的任务的执行进度
测试日志应该包含以下内容：
测试执行的环境 测试执行前的初始状态 测试的详细步骤 测试和系统的交互信息 测试期望的返回结果 测试实际的返回结果
