前言

日志用来记录用户操作、系统运行状态等，是一个系统的重要组成部分。然而由于日志并非系统核心功能，通常情况下并不受团队的重视。在出现问题需要通过日志来定位时，才发现日志还存在很多问题。

日志记录的好坏直接关系到系统出现问题时定位的速度，同时可以通过对日志的观察和分析，提前发现系统可能的风险，避免线上事故的发生。

我们在开发和运维NOS（网易对象存储，Netease Object Storage）的过程中，对整个系统的日志进行了分析优化，积累出一些经验，归纳如下。

相关问题经验整理

1.关于日志级别

我们通常使用的日志库（如log4j等），将日志基本分为以下几类（从低到高）：

TRACE-TheTRACELeveldesignatesfiner-grainedinformationaleventsthantheDEBUG
DEBUG–TheDEBUGLeveldesignatesfine-grainedinformationaleventsthataremostusefultodebuganapplication.
INFO-TheINFOleveldesignatesinformationalmessagesthathighlighttheprogressoftheapplicationatcoarse-grainedlevel.
WARN-TheWARNleveldesignatespotentiallyharmfulsituations.
ERROR-TheERRORleveldesignateserroreventsthatmightstillallowtheapplicationtocontinuerunning.
FATAL-TheFATALleveldesignatesverysevereerroreventsthatwillpresumablyleadtheapplicationtoabort.

尽管log4j官方文档对各个日志级别进行了简单定义。然而在实践中，究竟哪些操作需要记入日志，哪种错误应该记为WARN级别，而哪种错误又为ERROR级别，还需要进行进一步讨论。

关于该问题，在StackOverflow上有一个讨论贴进行过讨论。

此处对贴子中的一些观点，加上我们在平时运维过程中遇到的相关问题进行归纳：

• 一个项目各个log级别的定义应该是清楚明确的，是每个开发人员所遵循的；
• 即使是TRACE或者DEBUG级别的日志，也应该有一定的规范，要保证除了开发人员自己以外，包括测试人员和运维人员都可以方便地通过日志定位问题；
• 对于日志级别的分类，有以下