【.com快译】微服务架构是一种新的应用结构，可以帮助你通过松散耦合的系统相互开发、测试、部署和发布各种服务，相互独立其他。所以微服务背后的思想是：把一个大系统分解成许多独立的小部分。通常，每个服务都通过HTTP端点与其他服务交互。在隐藏技术栈细节的同时，他们会将自己的合约暴露给相应的消费者角色。例如：服务A可以在调用服务B的同时调用服务C，只要整个请求链完整，服务A就可以响应发起请求的客户端。微服务架构可以给我们的系统带来很多好处。它的主要能力包括：使用不同的技术栈，独立部署，一次只解决一个小问题。但是，由于其在通信和管理上的复杂性，使用微服务的成本普遍较高。当一个或多个服务失败时，微服务会变得更加复杂。如果没有好的、有意义的日志，您将无法回答以下问题：哪个服务失败、为什么失败以及在什么情况下失败。老实说，我个人非常讨厌一些因日志记录策略不当而导致的“未知”系统错误。下面和大家分享一下我在处理微服务的时候总结出来的7个好的实践。1.使用唯一的ID来关联每个请求请回忆一下我们上面提到的服务A、B、C之间的请求调用链。在实践中，我们应该为每个调用分配一个唯一的ID来标识每个请求。假设您正在记录每个服务的访问和错误日??志。如果您在服务B上看到错误，那么您就知道错误是来自服务A还是服务C。如果错误消息足够详细，您可能不必重现错误。但大多数情况下并非如此，你必须以正确的方式重现每个服务（如服务B）中所有请求的错误。因此，如果您找到与之关联的请求，您需要做的就是在日志中查找它的ID。然后，您可以顺藤摸瓜地从服务的完整日志中提取系统的那些主要请求的某个部分。然后您可以查看哪个服务的主要请求花费的时间最多。可能性包括：也许一个服务正在使用缓存，或者一个服务不止一次调用其他服务，以及其他有趣的细节。2.在响应中包含唯一ID的微服务用户可能会多次遇到相同的错误。面对这种情况，您应该抓住机会对客户端可能收到的响应进行编码，以便它可以传递一个唯一的ID，以及与错误相关的任何其他有用信息。当然这个唯一ID可以和我们上面提到的相关请求完全一致。因此，在响应负载中包含与请求关联的唯一ID将帮助您和您的客户更快地发现问题。同时，您还可以了解到请求日期、时间等参数的详细信息，以便您更好地了解您遇到的问题。或者，您可以将请求ID添加到常见的补充错误消息中，例如“请联系服务管理员并报告问题”。深入了解导致错误的原因并防止它在将来再次发生。3.将日志发送到集中位置这里，让我们假设您已经将各种有用的日志信息分类。接下来，我们需要将各种日志发送到一个集中的位置。试想一下：如果您每次都必须登录到不同的服务器以读取不同的日志信息，您将不得不花费更多时间来尝试关联这些问题。这比登录到一个位置并访问一个地方的所有日志来定位问题要好得多。此外，您的系统通常会随着时间的推移变得越来越复杂，单个微服务的数量也在不断增加。同时，您的各种服务可能位于不同的服务器或提供商上，这会使情况进一步复杂化。因此，日志的集中存储正在成为业界的普遍做法，尤其是当您的服务工作在云、容器或其他混合环境中时，某些服务器可能会在没有任何通知的情况下下线。例如，有些容器会在发生异常错误时被终止，或者内存消耗水平已经达到100%。您可以通过设置代理在服务器关闭前每五分钟推送/拉取日志来解决此问题。您还可以在服务器上配置一个cronjob（定时任务）、sidecar容器或与其他进程共享的文件位置，以集中各种日志。为了避免日志被篡改，你也可以自己构建一个解决方案。详情请参考链接：https://blog.scalyr.com/2017/11/log-management-need/。可见，将所有服务的日志集中在一个地方，可以帮助您更方便、更有效地定位各种相关问题。4.构造你的日志数据在实践中，我们很难预先定义所有日志数据的格式。有些日志可能需要比其他日志更多的字段，相反，这些字段可能是多余的，并且对于那些不需要的日志来说会浪费字节。微服务架构通过使用不同的技术栈来解决此类问题。但是，这会影响每个服务的日志格式。例如：一项服务可能使用逗号分隔不同的字段，而其他日志使用管道或命名空间。上面的方法显然比较复杂。因此，我们可以通过将自己的日志数据构建成标准格式，例如JavaScriptObjectNotation(JSON)，来简化解析日志的过程。JSON允许您拥有多层数据。必要时，您可以在单个日志事件中获取更多语义信息。同时，这种方式也让特定日志格式的解析变得更加直接。通过构建数据结构，即使您的日志具有各种字段，格式也会变得更加标准。有了它，您还可以在集中位置创建各种搜索，例如，通过“HTTP_CODE”字段检索包含500条或更多条目的日志信息。可以说，使用结构化的日志方式，不仅可以规范你的微服务日志，还可以保持灵活性。5.为每个请求添加上下文通常，如果系统能够提供足够的信息，那么我们就可以更好地理解问题的上下文请求，更快地找到问题的根本原因。但是，为各种日志添加上下文也会在代码级别创建一些重复性工作，因为您需要的许多日志事件已经包含日期和时间等公共数据信息。因此，在我们的代码中，我们应该只记录那些重要的消息，并涉及一些特定的字段，这样日志看起来简单明了。您可能会想到各种需要记录的数据，但让我们用下面的列表来告诉您哪些是真正需要记录的具体区域。日期和时间。当然，如果你能保证读取日志的人在同一个时区，就不用一直使用UTC（CoordinatedUniversalTime）格式了。堆栈错误。您可以将异常对象作为参数传递给您自己的日志记录库。服务的名称或代码，因此可以根据微服务区分不同的日志。发生错误的函数、类或文件的名称，可节省您追查问题根源的时间。与外部服务交互的各种名称，例如：您可以知道哪个进程在调用数据库时遇到问题。服务器和客户端请求的IP地址。此信息将帮助您发现不健康的服务器或识别DDoS攻击。应用程序的用户代理，因此您可以知道哪个浏览器或用户有问题。通过HTTP代码获取错误的更多语义。这些代码将有助于创建各种警报。可以看出，为每个请求添加上下文可以节省您对系统进行故障排除的时间。6.将日志存储在本地将日志存储在本地听起来可能与我们前面所说的“将日志发送到一个集中的位置”相矛盾，但事实并非如此。最初，我是直接通过HTTP请求将各种日志发送到其他地方。但是我反复发现这些流量中转占用了我大量的出带宽，以至于影响了其他更重要的微服务调用。因此，我们需要在日志的传出存储和本地存储之间做出权衡。最终，我选择了本地存储，因为它有助于将日志与应用程序分开并减少上下文切换。对于数据库，您可以通过将应用程序与其在不同存储卷上的日志分开来实现。例如：亚马逊的AWS是一个选项。用户可以使用称为弹性文件系统(EFS)的服务来挂载卷。它的功能类似于网络附加存储（NAS）。然后，您可以根据需要转移到另一台服务器，安装相同容量的卷，并将各种日志转发到该集中位置。简单地说，我们可以使用Docker容器将所有应用程序日志发送到同一个位置。然后将这些日志的存储库聚合、过滤并转发给其他进程或服务。7、记录重要有意义的数据，做好准备。如果你是微服务的日志问题的新手，以上最佳实践可能对你来说“无所谓”。但是，只要你足够细心，在你使用微服务一段时间后，你可以通过评估现有的日志信息和方法，逐渐找出哪些有用的信息可以用来发现和解决奇怪的问题.同时，在记录和积累足够的日志数据后，您还可以伺机采用自动化告警的方式，省去您阅读大量日志来定位问题的时间。当然，自动警报还可以帮助您以主动的方式将错误传播给所有用户。总之，集中的日志信息是微服务错误分析必不可少的手段。在日志中添加足够的上下文信息可以更好地区分那些有用的日志和无用的日志。原标题：微服务日志记录最佳实践，作者：ChristianMelendez&DavidMcAllister
