过程
打印日志到分析查询之间，还隔着收集、缓冲、聚合、加工、索引、存储等若干个步骤，如下图所示：
输出
要是说好的日志能像文章一样，让人读起来身心舒畅，这话肯定有夸大的成分，不过好的日志应该能做到像“流水账”一样，可以毫无遗漏地记录信息，格式统一，内容恰当。其中，“恰当”是一个难点，它要求日志不应该过多，也不应该过少。
不该出现的内容不要有
1、避免打印敏感信息
不用专门去提醒，我们肯定都知道不该把密码、银行账号、身份证件等这些敏感信息打到日志里，但我就见过不止一个系统的日志中，能直接找到这些信息。一旦这些敏感信息随日志流到了后续的索引、存储、归档等步骤后，清理起来就会非常麻烦
2、避免引用慢操作
日志中打印的信息应该是在上下文中可以直接取到的，而如果当前的上下文中根本没有这项数据，需要专门调用远程服务或者从数据库中获取，又或者要通过大量计算才能取到的话，那我们就应该先考虑下，这项信息放到日志中是不是必要且恰当的
3、避免打印追踪诊断信
即日志中不要打印方法输入参数、输出结果、方法执行时长之类的调试信息。这个观点其实是反直觉的，不少公司甚至会提倡把这一点作为最佳实践，但是我仍然坚持把它归入反模式中。这是因为日志的职责是记录事件，而追踪诊断应该由追踪系统去处理，哪怕贵公司完全没有开发追踪诊断方面功能的打算，我也建议使用BTrace或者Arthas这类“On-The-Fly”的工具来解决。还有，我之所以将其归为反模式，也是因为前面所说的敏感信息、慢操作等主要源头，就是这些原本想用于调试的日志。比如，当前方法入口参数有个 User 对象，如果要输出这个对象的话，常见的做法是将它序列化成 JSON 字符串，然后打到日志里。那么这个时候，User 里面的 Password 字段、BankCard 字段就很容易被暴露出来。再比如，当前方法的返回值是个 Map，我们在开发期的调试数据只做了三五个 Entity，然后觉得遍历一下把具体内容打到日志里面没什么问题。而到了生产期，这个 Map 里面有可能存放了成千上万个 Entity，那么这时候打印日志就相当于引用慢操作了。
自己思考：对外交互的接口，排开批量查询的接口，还是建议能打则打。避免扯皮。
4、避免误导他人
明明已经在逻辑中妥善处理好了某个异常，只是偏习惯性地调用 printStackTrace() 方法，把堆栈打到日志中，那么一旦这个方法附近出现问题，由其他人来除错的话，就很容易会盯着这段堆栈去找线索，从而浪费大量时间。
该出现的内容不要少
1、处理请求时的 TraceID
当服务收到请求时，如果该请求没有附带 TraceID，就应该自动生成唯一的 TraceID 来对请求进行标记，并使用 MDC 自动输出到日志。TraceID 会贯穿整条调用链，目的是通过它把请求在分布式系统各个服务中的执行过程给串联起来。TraceID 通常也会随着请求的响应返回到客户端，如果响应内容出现了异常，用户就能通过此 ID 快速找到与问题相关的日志。这个 TraceID 其实是链路追踪里的概念，类似的还有用于标识进程内调用状况的 SpanID，在 Java 程序中，这些都可以用 Spring Cloud Sleuth 来自动生成。另外，尽管 TraceID 在分布式追踪系统中会发挥最大的作用，但对单体系统来说，将 TraceID 记录到日志并返回给最终用户，对快速定位错误也仍然十分有价值
2、系统运行过程中的关键事件
我们都知道，日志的职责就是记录事件，包括系统进行了哪些操作、发生了哪些与预期不符的情况、在运行期间出现了哪些未能处理的异常或警告、定期自动执行的各种任务，等等，这些都应该在日志中完整地记录下来。那么原则上，程序中发生的事件只要有价值，就应该去记录，但我们还是要判断清楚事件的重要程度，选定相匹配的日志的级别。至于如何快速处理大量日志，这是后面的步骤需要考虑的问题，如果输出日志实在太频繁，以至于影响到了性能，就应该由运维人员去调整全局或单个类的日志级别来解决。
3、启动时输出配置信息
与避免输出诊断信息不同，对于系统启动时或者检测到配置中心变化时更新的配置，就应该把非敏感的配置信息输出到日志中，比如连接的数据库、临时目录的路径等等，因为初始化配置的逻辑一般只会执行一次，不便于诊断时复现，所以应该输出到日志中。
