使用Slf4j或者诸多日志框架时，可以看到不少日志级别，我们常用INFO和ERROR，对其他级别没有过多的使用，但是不意味着它们没有价值，存在即合理，我们需要正确的使用日志级别来构建应用，而正确的使用来自于一致的理解。
Fatal/Critical级别：应用或者系统上的失败需要立即被关注，这种情况下需要立即叫醒系统管理员。因为我们希望系统管理员能够睡个好觉，所示这种级别的问题是很少见的，至少非常不频繁。如果这种问题日常经常发生，最终证明实际上又不是个大问题，那就失去它的作用。一般来说，一个Fatal的错误会出现在应用进程最后的时刻，往往是日志中的最后一段内容。
Error级别：这是一个需要被关注的问题。系统管理员最好能够被自动通知，但是不需要立即被叫起床，因为这种错误往往不是全面的。通过查看错误日志，能够粗略的得到错误的频度以及导致这个错误出现的原因，它可能是系统的一个错误，但不一定是源头，通过定位错误数据的来源以及场景，在接下来的工作中进行修复。举个例子，这些错误信息是否出现是决定接下来发布的衡量标准。
Warning级别：这可能是一个问题，或许不是。举个例子，如果环境中的信息出现变化，比如数据库连接断开，这个场景应该被记录为Warning，而非Error。通过观察Warning日志能够让我们快速找到导致错误的起始原因，Warning使用时需要特别注意，放置使它变得没有意义。在服务端应用断开连接的场景下，使用Warning是比较合适的，但是如果在一个桌面程序上，当连接断开时进行Warning，就没有太大必要，因为这个场景经常出现，使用Info就足够了。
Info级别：在正常情况下需要被记录的重要信息，例如：系统初始化成功，服务启动或者停止以及成功的处理了重要的业务。查看日志中的Info信息，能够看到应用提供服务的主要状态变更，但是也不要记录过多的Info信息。该级别一般是应用默认的日志级别。
Debug级别：该信息能够提供给开发人员，帮助其定位系统运行的路径以及产生问题的场景和数据，对于系统管理员来说这个就不一定能够产生价值了。
Trace级别：Trace是一个需要被严肃对待的级别，它在记录的同时，提供了应用进入该状态时的上下文，这样就能更加容易的分析出问题的原因。Trace容易受到代码修改导致的影响，因此需要开发团队能够定期的维护日志输出，这样在问题出现时就更容易定位问题。同时也需要鼓励开发团队将不再需要的Trace语句清除并添加新的需要的日志输出，比如：记录用户的输入等。同样这个日志级别，对于开发人员有用，但是对于系统管理员就意义不大了。
网友评论