调试分布式应用程序的最佳工具

最新推荐文章于 2024-09-10 22:35:44 发布

Tybyqi

最新推荐文章于 2024-09-10 22:35:44 发布

阅读量637

点赞数

分类专栏： Web开发

本文链接：https://blog.csdn.net/Tybyqi/article/details/83186120

版权

Web开发专栏收录该内容

14 篇文章 0 订阅

订阅专栏

诸如Kubernetes这样的分布式系统给现代应用程序栈带来了许多优势，但也带来了许多复杂和可移动的部件。当某件事情确实出错，或者没有按计划进行时，找出原因比使用“传统”应用程序要复杂得多。可能有几个因素和并发症。

制度不一致

虽然Kubernetes吊舱和Docker容器可以帮助您保持一些一致性，但它们通常运行在各种不同的底层机器上，所有这些都会带来组件、操作系统和小版本更改方面的细微差别。

分布式系统的本质往往带来编程语言、存储标准和它们之间通信协议的混合。大多数现代工具使用诸如JSON之类的标准进行数据交换、RPC、RESTful接口或消息总线，虽然这些标准解决了标准问题，但它们引入了另一个组件以添加到调试过程中。

谁先到那里

当系统中发生事件时，会发生争用条件或不一致的并发，但不按您所期望的顺序进行。这在任何体系结构中都是一个常见的问题，但由于分布式系统具有多个组件、实例、网络速度和系统资源的竞争，这一问题更加复杂。

维护真理

与上述密切相关的是维护应用程序中数据值的真相来源。如果多个应用程序可以写入一个事件的值，那么我们认为正确的答案是什么？如果集群中的元素在传输过程中遇到停机和数据丢失怎么办？同样，您认为最后一个一致状态是什么，以及如何恢复它？有一些容器设计模式有助于使这些过程更易于管理，但有时您仍然需要更深入地挖掘。

解

调试容器

调试容器内部发生的事情比在本地机器上运行代码时要复杂得多。而命令如附附, 主管, 原木, 统计和顶(以及他们的Kubernetes等价物)的帮助，他们只带您到目前为止，特别是作为一个应用程序规模使用多个容器。

常见的容器设计模式鼓励您创建尽可能小的容器，为捆绑您可能需要或不需要的调试工具提供很少的空间。输入“的概念Sidecar容器“当您需要时，可以为其他容器提供服务，而不会混淆您的核心容器。在这些容器中，您可以打包工具，例如箱箱，或者我们在这篇文章的其余部分中介绍的其他一些工具。

把所有的东西都记录下来

当事情出错时，日志总是您的朋友，使用Kubernetes，您的集群、容器和应用程序都会生成日志。问题不在于缺乏信息，而是将其解析为有用的东西。除了将输出写入标准输出和错误流之外，这些日志源都不提供读取或存储输出的任何方法。为了获得最大的效用，您需要一个单独的后端，具有讽刺意味的是，添加了一个可能需要调试的额外组件。

您可以直接从应用程序级别登录到适合语言或应用程序的日志后端。

您可以在群集节点级别登录，再次登录到您选择的后端，并使用DaemonSet若要在集群中复制服务，请执行以下操作。

在集群级别上，您可以使用上面提到的Sideecar容器，定期从应用程序容器收集日志并将它们传递给日志后端。

对于后两个选项，Kubernetes支持流d，它是许多后端支持的开源数据收集器。

欲知更多详情阅读Kubernetes日志指南.

还有一些商业日志工具可用，例如DataDog、NewRelic和LightStep，它们在一个接口中为您处理所有级别的应用程序堆栈。

追踪

再往前走一步，追踪允许您跟踪应用程序组件的执行，帮助您深入了解哪里出错了。随着分布式应用程序的普及，分布式跟踪工具也越来越流行，提供了一个有价值的概述，帮助您跟踪跨集群执行工作负载。

有一些流行的跟踪工具，如开放跟踪, 齐普金, 枢轴追踪和杰格，但是项目的考虑事项类似于日志记录。您需要架构您的应用程序、节点和集群以适应跟踪库，这意味着它为您提供了发现问题的无与伦比的能力，但必须在您投入大量时间之后才能完成。

事件源

为了帮助保持状态和并发性，或者至少帮助理解它是如何到达它所在的位置，需要考虑的另一个想法是：事件来源。而不是在应用程序中维护状态，而是维护事件的不断更新日志，以及在外部存储中触发事件的原因。然后，如果应用程序状态有疑问，并且需要调试所发生的情况，则需要重播导致应用程序运行的事件，以确定应用程序应处于何种状态。