¶ 库
¶ 级别
在同一个项目（乃至公司）中，日志级别的选取，应当遵循同样的规则。一般而言，会考虑以下因素：
- 日志需要关注的层次。关注的层次如：需要立即响应、不需要响应的异常、关键决策、执行过程、执行过程的参考信息。
- 日志的体量。比如需要立即响应的日志，体量不应该多，如果数据量非常大，放在需要立即响应并不是合理的方案。
常见的也有其它的因素，但是并不一但可取：
- 异常本身的重要性。是不是异常是客观的，而异常有多重要则是主观的。作为级别设定，应当以客观因素为基准来决定。否则不利于统一。要么处理异常，要么打
ERROR。严格避免既不处理异常，然后打INFO或根本不打。
¶ 级别的选择
日志级别的选择，发生在两个地方：
- 记录日志时，记录成什么级别
- 输出日志，把什么级别的日志输出
一般而言，记录日志的级别，以事情本身的性质决定级别。而日志输出的级别，会依据事情发生的环境和上下文来决定。比如，在应用级服务上，低层的内存缺页，网站IO异常，其本身的性质，决定了他至少是一个WARN。但是由于应用级所使用的库，已经处理好了IO异常，就并不需要把这些WARN输出出来。应当避免，因为不想输出出来，就去调整记录日志的级别的情况。
恰恰是因为日志的输出级别，常常需要结合上层服务的上下文，所以并不适合在公共的库中进行统一的控制。需要每个服务，结合自身的性质和环境，合理地设定日志输出的级别。
¶ 级别的环境差异
不同环境中的日志记录与输出级别应当保持一致。以保持不同环境之间行为的一致性。（本地环境可除外）
避免在代码上出现类似以下的行为——以环境决定日志记录的级别：
/** DON'T DO THIS **/
if (env == "prod") {
log.error("")
} else {
log.info("")
}
也要尽量避免形如以下的配置——以环境决定日志输出的级别：
logging:
level:
root: INFO
---
spring:
profiles: prod
logging:
level:
# DON'T DO THIS
root: WARN
¶ 格式
¶ 纯文本
使用空格分隔不同信息要素的纯文本，一般每条日志独占一行（考虑到异常信息和数据信息本身可能存在换行）。可读比较好，但是不便于后期的数据处理与分析。
日志格式的统一性，在微服务体系下非常重要。格式的不一致，会给后续的数据分析和处理带来困难。
¶ Json
使用Json格式化的日志可以承载更多信息。而且数据解析的质量更高。但是直接可读性，相比于纯文本略差。适用于有成熟的工具链的场景下。
¶ 输出
日志输出的方式，会影响到日志采集的方式。需要根据系统架构选取合适的日志输出方式。
根据12-factors原则，在虚拟化的微服务构架体系下，建议将日志输出到标准输出，而非文件中[1]。
¶ 内容
¶ 信息要素
服务端日志应当包括以下信息：
- 精确到（至少）毫秒的时间（建议全部UTC）。这个时间应当是事件的发生时间，而非日志被记录的时间。
- 级别
- 执行线程名（及可选的ID）
- 输出日志的主体。一般可以是类名。
- 日志消息体。
¶ 文体与信息
其中日志消息体因为由软件工程师编写，建议遵循以下原则：
- 一般使用简练的过去式叙事体。
- 语法结构及信息量相对完整的整句。
- 携带足够的上下文与细节信息。
- 对于错误信息，最好同时提供可能的解决方案。
¶ 位置
¶ 分支
一般分支表达某种决策，关键决策的结果应当以输出到日志中。
¶ 入出口
所有的方法的出入口及代码过程中的return及break语句，如果涉及到事件做与不做的问题，应当记录成日志。
¶ 异常
所有捕获的异常，如果没有做业务层面的处置，则必须输出成错误日志；如果有做处置，也应当作为关键信息记录。
¶ 使用模式
¶ DON'T
- 除特殊类型的库或插件，不建议把logger作为方法参数传递。
- 在不同的类中使用同一个logger类。
- 除非有实际的必要，不要直接将整个POJO类序列化输出。
¶ DO
- 使用日志抽象层，如slf4j。
- 将
logger声明为私有静态成员。 - 控制消息体的大小。