前面一篇《流行日志框架的简单介绍》简单介绍了下现有的日志框架，这篇我们将着重来讨论如何使用日志框架，为自己的项目搭建一个好的日志系统。
- 团队内成员需要明确并遵守日志级别
FATAL - 表示需要立即被处理的系统级错误。当该错误发生时，服务已经出现了某种程度的不可用，系统管理员需要立刻处理。这是最严重的日志级别，因此该日志级别要慎用，如果这种级别的日志经常出现，那这日志也失去了意义。通常情况下，一个进程的生命周期中应该只记录一次FATAL级别的日志，即该进程遇到无法恢复的错误而退出时。
TRACE - 主要作用是对系统每一步的运行状态进行精确的记录。通过它，可以查看某一个操作每一步的执行过程，精确定位是什么操作，有什么参数，执行顺序是怎样，最终导致了什么错误的发生。同时可以保证在不重现错误的情况下，通过分析 TRACE 级别的日志即可完成对问题的诊断。
ERROR - 该级别的错误也需要马上被处理，但是紧急程度要低于FATAL。当ERROR错误发生时，已经影响了正常的业务功能。FATAL相当于整个服务已经挂了，而ERROR表示系统出现错误，但还能提供服务。特别需要注意的是，ERROR应当属于服务自己的异常，是需要马上得到人工介入并处理的，如果出现了ERROR日志业务上又不需要处理的就不应该记为ERROR级别，这一点是区别于INFO的明显标识。例如由于用户自己操作不当，传入非法请求参数时，是绝对不应该记为ERROR级别；还有业务处理结果为失败的情况，比如扣款操作遇到用户余额不足，也不能记为ERROR。
INFO - 该种日志记录系统处理业务的概要信息，例如一个业务请求的入参和执行结果以及耗时等等。通过查看INFO级别的日志，可以很快地对系统中业务情况有个基本了解，有哪些业务处理成功哪些又失败了。INFO日志不宜过多，太多的话造成信息干扰不利于查问题；
WARN - 该日志表示系统可能出现问题，也可能没有，标识的是系统潜在问题。对于WARN级别的日志，虽然不需要系统管理员马上处理，也是需要即使查看并处理的。因此此种级别的日志也不应太多，能不打WARN级别的日志，就尽量不要打；
绝不打印没有用的日志，防止无用日志淹没重要信息。
团队内，日志的格式要统一： logback中pattern的格式，日志的大小，轮转策略...
日志分类
a. info.log：业务关键步骤信息。
b. error.log：业务发生的错误以及堆栈信息。
c. sql_info.log：超过10ms的SQL调用。
d. api_info.log：api调用的关键信息。
e. rpc_info.log：rpc调用的信息。日志里记录的信息
a. 请求参数
b. tracId，追逐日志的唯一id（traceId 的作用是把分散在各个日志文件中的日志信息都串起来，一个请求产生的所有日志都有同一个唯一的 traceId）
c. 请求客户端IP
d.响应参数
e. 处理耗时
上文中提到的traceId，可以在 Controller 的 AOP 中使用 slf4j MDC 把 traceId 放到线程上下文，对业务编码并无入侵
