一、什么是日志
日志用来记录用户操作、系统运行状态等，是一个系统的重要组成部分。然而，由于日志通常不属于系统的核心功能，所以常常不被团队成员所重视。对于一些简单的小程序，可能并不需要在如何记录日志的问题上花费太多精力。但是对于作为基础平台为很多产品提供服务的后端程序，就必须要考虑如何依靠良好的日志来保证系统可靠的运行了。
好的日志可以帮助系统的开发和运维人员：
- 了解线上系统的运行状态
- 快速准确定位线上问题
- 发现系统瓶颈
- 预警系统潜在风险
- 挖掘产品最大价值
不好的日志导致：
- 对系统的运行状态一知半解，甚至一无所知
- 系统出现问题无法定位，或者需要花费巨大的时间和精力
- 无法发现系统瓶颈，不知优化从何做起
- 无法基于日志对系统运行过程中的错误和潜在风险进行监控和报警
- 对挖掘用户行为和提升产品价值毫无帮助
二、日志分类
日志从功能来说，可分为诊断日志、统计日志、审计日志。
诊断日志， 典型的有：
- 请求入口和出口
- 外部服务调用和返回
- 资源消耗操作: 如读写文件等
- 容错行为： 如云硬盘的副本修复操作
- 程序异常： 如数据库无法连接
- 后台操作：定期执行删除的线程
- 启动、关闭、配置加载
统计日志：
- 用户访问统计：用户IP、上传下载的数据量，请求耗时等
- 计费日志（如记录用户使用的网络资源或磁盘占用，格式较为严格，便于统计）
审计日志：
- 管理操作
对于简单的系统，可以将所有的日志输出到同一个日志文件中，并通过不同的关键字进行区分。而对于复杂的系统，将不同需求的日志输出到不同的日志文件中是必要的，通过对不同类型的文件采用不同的日志格式（例如对于计费日志可以直接输出为Json格式），可以方便接入其他的子系统。
三、日志中记录什么
理想的日志中应该记录不多不少的信息。
所谓不多，是指不要在日志中记录无用的信息。实践中常见到的无用的日志有：1）能够放在一条日志里的东西，放在多条日志中输出；2）预期会发生且能够被正常处理的异常，打印出一堆无用的堆栈；3）开发人员在开发过程中为了调试方便而加入的“临时”日志
所谓不少，是指对于日志的使用者，能够从日志中得到所有需要的信息。在实践中经常发生日志不够的情况，例如：1）请求出错时不能通过日志直接来定位问题，而需要开发人员再临时增加日志并要求请求的发送者重新发送同样的请求才能定位问题；2）无法确定服务中的后台任务是否按照期望执行；3）无法确定服务的内存数据结构的状态；4）无法确定服务的异常处理逻辑（如重试）是否正确执行；5）无法确定服务启动时配置是否正确加载；
四、关于日志级别
我们通常使用的日志库，将日志基本分为以下几类（从低到高）： TRACE – The TRACE Level designates finer-grained informational events than the DEBUG DEBUG – The DEBUG Level designates fine-grained informational events that are most useful to debug an application. INFO – The INFO level designates informational messages that highlight the progress of the application at coarse-grained level. WARN – The WARN level designates potentially harmful situations. ERROR – The ERROR level designates error events that might still allow the application to continue running. FATAL – The FATAL level designates very severe error events that will presumably lead the application to abort.
开发人员对于何种日志输出为何种级别通常有自己的理解，那在实践中，是否所有的日志级别都有必要存在，哪些操作需要记入日志，哪种错误应该记为WARN级别，而哪种错误又为ERROR级别呢？关于该问题，可以参考StackOverflow上的一个讨论。
此处对贴子中的一些观点，加上我们在平时运维过程中遇到的相关问题进行归纳：
- 一个项目各个日志级别的定义应该是清楚明确的，需要团队的每个开发人员共同遵守；
- 即使是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）日志来定位问题；