为每个请求添加上下文
通常情况下，如果系统能够提供足够的信息，那么我们就能够更好地了解针对某个问题的上下文请求，更快地发现该问题的根本原因。不过，给各种日志添加上下文，也会在代码层面上产生一些重复性的工作，因为在您所需要的许多日志事件中，已经包含了诸如日期和时间等通用数据信息。因此在我们的代码中，应当只记录那些重要的消息、并涉及到一些特定的领域，以使得日志看起来简单明了。
您可能会想到各种五花八门的数据需要被记录，但是让我们通过如下的列表，来告诉您哪些才是真正需要记录的具体特定领域吧。
u 日期和时间。当然，如果能够保证读取日志的人都在同一时区的话，您大可不必一律采用UTC（世界标准时间）的格式。
u 堆栈错误。您可以将异常对象作为参数传递给自己的日志库。
u 服务的名称或代码，这样您就可以根据微服务来区分不同的日志。
u 发生错误的函数、类或文件名，这样您就省去了跟踪问题出处的时间。
u 与外部服务交互的各种名称，例如：您可以获悉是哪个进程在调用数据库时出现了问题。
u 服务器和客户端请求的IP地址。这些信息将有助于发现那些不健康的服务器、或识别出DDoS类攻击（https://en.wikipedia.org/wiki/Denial-of-service_attack）。
u 应用程序的用户代理，以便您能判断是哪些浏览器或用户碰到了问题。
u 通过HTTP代码来获取错误的更多语义。这些代码将有助于创建各类警报。
可见，为每个请求添加上下文，能够节省您对系统进行排障的时间。
将日志存储到本地
将日志存储到本地，似乎听取来和我们前面说的“发送日志到集中的位置”有些矛盾，其实则不然。最初我是将各种日志，直接通过HTTP请求的方式发送到别处的。但是我屡次发现这些流量传输占用掉了我大量的出站带宽，以至于影响到了其他更为重要的微服务调用。
因此，我们需要对日志的外发和本地存储有所取舍。最终，我之所以选择了本地存储，是因为这样有助于从应用程序中分离日志、并减少上下文的切换。针对数据库，您可以采取将应用程序与其日志区分不同存储卷的方式。例如：亚马逊的AWS（https://aws.amazon.com/）就一个选项，用户可以使用一种称为Elastic File System（EFS，https://aws.amazon.com/efs/）的服务，去挂载某个卷。其功能类似于网络附属存储（network-attached storage，NAS）。那么，您可以按需辗转到另一台服务器上，挂载相同容量的卷，然后将各种日志转发到那个集中的位置上。
简单说来，我们可以使用Docker容器，来实现将所有应用程序的日志都发送到相同的位置。然后汇总、过滤和转发这些日志的存储库，到其他进程或服务那里。
记录重要且有意义的数据，有备无患
如果您是刚开始接触微服务的日志问题，那么上述最佳实践可能会对你比较“无感”。但是，只要您足够细心，在持续使用了微服务一段时间之后，您就可以通过对现有日志信息和方式的评估，逐渐摸索出哪些才是您可以用来发现和解决奇怪问题的有用信息。
同时，在记录和积累了足够多的日志数据之后，您还可以伺机采用自动化的警报方式，以节约您通过读取大量日志来定位问题的时间。当然，自动化警报也能够帮助您以一种积极主动方式，限制各种错误向所有用户处蔓延。
总之，集中化日志信息，是微服务错误分析的必备手段。而为日志添加足够多的上下文信息，则能够更好地分辨出那些有用的日志和无用的信息。
【原标题】Microservices Logging Best Practices (作者: Christian Melendez & David McAllister)
原文链接：https://dzone.com/articles/microservices-logging-best-practices
