基础设施与应用监控之监视分布式和微服务系统

谁借莪１个温暖的怀抱￠ 2022-05-09 00:50 271阅读 0赞

# 介绍 #

系统和基础设施监控是各种规模的运营团队的核心职责。行业里已经开发了许多策略和工具，以帮助监控服务器，收集重要数据，并响应不同环境中的事件和不断变化的条件。但是随着软件方法和基础设施设计的发展，监控必须适应新的挑战并在相对不熟悉的领域提供洞察力。

到目前为止，在本系列中，我们已经讨论了[什么是指标，监控和警报][Link 1]以及良好的监控系统所具备的特征。我们讨论了从[基础架构和应用程序收集指标以及在整个基础架构中监控重要的信号][Link 2]。在我们的上一篇指南中，我们介绍了如何通过了解各个组件和良好警报设计的标准，将[指标和警报付诸实践][Link 3]。

在本文中，我们将了解高度分布式架构和微服务的监控和指标收集如何变化。云计算、大数据集群和容器编排层的日益普及迫使运营专业人员重新思考如何大规模设计监控，并通过更好的仪器解决独特的问题。我们将讨论新的部署模型有什么不同以及可以使用哪些策略来满足这些新需求。

# 高度分布式架构会带来哪些挑战？ #

为了模拟和镜像它所监视的系统，监控基础设施一直在某种程度上分布。然而，许多现代开发实践（包括围绕微服务，容器和可互换的短暂计算实例的设计）已经大大改变了监控环境。在许多情况下，这些变化的核心特征是使监测变得更困难的因素。让我们花一点时间来看一下这些与传统环境不同的方式以及它们如何影响监控。

## 工作与基础资源分离 ##

许多系统行为方式的一些最根本的变化是由于新的抽象层的爆炸式增长，软件可以围绕它设计。容器技术改变了已部署软件与底层操作系统之间的关系。部署在容器中的应用程序与外部世界、其他程序和主机操作系统的关系不同于通过传统方式部署的应用程序。内核和网络抽象可能导致对操作环境的不同理解，具体取决于您检查的层。

通过创建一致的部署策略，这种抽象级别在很多方面都非常有用，可以更轻松地在主机之间迁移工作，并允许开发人员对其应用程序的运行时环境进行严密控制。然而，这些新功能的代价是增加了复杂性，并且与为每个进程提供动力的资源建立了更为松散的关系。

## 增加基于网络的通信 ##

新架构中的一个共同点是越来越依赖内部网络通信来协调和完成任务。以前，单个应用程序的域可能会分散在需要协调和共享信息的许多组件中。这在通信基础设施和监控方面会产生一些影响。

首先，因为这些模型建立在小型离散服务之间的通信之上，所以网络健康变得比以往更加重要。在传统的，更加单一的体系结构中，协调任务、共享信息和组织结果主要是在具有常规编程逻辑的应用程序中或通过相对少量的外部通信来完成的。相反，高度分布式应用程序的逻辑流程使用网络进行同步，检查对等体的健康状况并传递信息。网络健康和性能直接影响比以前更多的功能，这意味着需要更密集的监控来保证正确的操作。

虽然网络变得比以往任何时候都更加重要，但由于参与者数量和个人通信线路的增加，有效监控网络的能力越来越具有挑战性。不是跟踪几个应用程序之间的交互，而是需要在数十个，数百个或数千个不同点之间进行正确的通信，以确保相同的功能。除了考虑复杂性之外，增加的流量还会给可用的网络资源带来额外的压力，进一步加剧了可靠监控的必要性。

## 功能和责任分配到更大程度 ##

上面，我们提到了现代架构在许多较小的分立组件之间划分工作和功能的趋势。这些设计可以对监控环境产生直接影响，因为它们使清晰度和可理解性特别有价值，但却越来越难以捉摸。

需要更强大的工具和仪器以确保良好的工作秩序。但是，由于完成任何给定任务的责任是分散的，并且在不同的工作单元（可能在许多不同的物理主机上）之间分配，因此理解责任在于性能问题或错误的位置可能很困难。触及许多组件的请求和工作单元（其中许多组件是从可能的候选者池中选择的），使用传统机制使请求路径可视化或根本原因分析变得不切实际。

## 短期和短暂的单位 ##

适应传统监测的进一步斗争是合理地追踪短期或短暂的单位。无论关注的单元是云计算实例，容器实例还是其他抽象，这些组件通常都违反了传统监控软件所做的一些假设。

例如，为了区分有问题的故障节点和故意销毁的实例以缩小规模，监控系统必须对您的配置和管理层有一个比以前更必要的了解。对于许多现代系统而言，这些事件发生的频率更高，因此每次手动调整监控域都是不切实际的。随着这些设计，部署环境变化更快，因此监控层必须采用新策略来保持价值。

许多系统必须面对的一个问题是如何处理来自被破坏实例的数据。虽然可以快速配置和取消配置工作单元以适应不断变化的需求，但必须决定如何处理与旧实例相关的数据。数据不一定会立即失去其价值，因为基础工作者不再可用。当每天有数百或数千个节点来来往往时，可能很难知道如何从短期实例的碎片化数据中最好地构建关于系统整体运行状况的叙述。

# 扩展监控需要哪些更改？ #

现在我们已经确定了分布式架构和微服务的一些独特挑战，我们可以讨论监控系统在这些现实中的工作方式。一些解决方案涉及重新评估和隔离对不同类型的指标最有价值的内容，而其他解决方案涉及新工具或理解其所处环境的新方法。

## 粒度和抽样 ##

服务数量增加导致的总流量增加是最直接的问题之一。除了由新架构引起的传输数量膨胀之外，监控活动本身可能开始陷入网络并窃取主机资源。为了最好地处理增加的数量，您可以扩展监控基础架构或降低使用数据的分辨率。这两种方法都值得关注，但我们将重点关注第二种方法，因为它代表了一种更具可扩展性和广泛有用的解决方案。

更改数据采样率可以最大限度地减少系统从主机收集的数据量。抽样是指标集合的正常部分，表示您为指标请求新值的频率。增加采样间隔将减少您必须处理的数据量，但也会降低数据的分辨率 - 细节级别。虽然您必须小心并了解最低有用分辨率，但调整数据收集率会对系统可以充分服务的监控客户端数量产生深远影响。

为了减少由较低分辨率导致的信息丢失，一种选择是继续以相同的频率在主机上收集数据，但将其编译成更易消化的数字以便通过网络传输。各个计算机可以聚合和平均度量值，并将摘要发送到监控系统。这有助于在保持准确性的同时减少网络流量，因为仍然考虑了大量数据点。请注意，这有助于减少数据收集对网络的影响，但本身并不能帮助解决在主机中收集这些数字所带来的压力。

## 根据多个单元聚合的数据做出决策 ##

如上所述，传统系统和现代架构之间的主要区别之一是分解哪些组件参与处理请求。在分布式系统和微服务中，通过某种类型的调度或仲裁层，更有可能将工作单元提供给工作池。这对您可能围绕监控构建的许多自动化流程都有影响。

在使用可互换工作池的环境中，运行状况检查和警报策略可能会增长，与其监视的基础结构之间存在复杂的关系。对个别单位进行健康检查对于自动退役和回收有缺陷的单位非常有用。但是，如果您具有大规模自动化，则单个Web服务器在大型池中出现故障并不重要。系统将自我纠正，以确保只有健康单位在活动池中接收请求。

虽然主机运行状况检查可以捕获有缺陷的单元，但检查池本身的运行状况更适合于警报。池满足当前工作负载的能力对用户体验的影响大于任何单个工作者的能力。基于健康成员数量，池聚合延迟或池错误率的警报可以通知操作员更难以自动缓解并且更可能影响用户的问题。

## 与供应层集成 ##

通常，分布式系统中的监视层需要更全面地了解部署环境和配置机制。由于这些体系结构中涉及的单个单元的数量，自动化生命周期管理变得非常有价值。无论这些单元是原始容器，业务流程框架内的容器还是云环境中的计算节点，都存在一个管理层，它公开健康信息并接受命令来扩展和响应事件。

游戏中的棋子数增加了统计失败的可能性。在所有其他因素相同的情况下，这需要更多的人为干预来回应和缓解这些问题。由于监控系统负责识别故障和服务降级，如果它可以挂钩到平台的控制接口，它可以缓解大量这些问题。监控软件触发的即时自动响应有助于维护系统的运行状况。

监控系统和部署平台之间的这种紧密关系在其他架构中不一定是必需的或共同的。但是，自动化分布式系统旨在实现自我调节，能够根据预先配置的规则和观察到的状态进行扩展和调整。在这种情况下，监控系统在控制环境和决定何时采取行动方面发挥着核心作用。

监控系统必须了解供应层的另一个原因是处理短暂实例的副作用。在工作实例中频繁更换的环境中，监控系统依赖来自旁道的信息来了解何时有意或无意地采取行动。例如，当服务器故意被操作员销毁时，与服务器突然变得没有响应而没有相关事件时，可以从供应者读取API事件的系统做出不同的反应。能够区分这些事件可以帮助您的监控保持有用、准确和可信，即使底层基础架构可能经常更改。

## 分布式跟踪 ##

高度分散的工作负载中最具挑战性的方面之一是了解不同组件之间的相互作用，并在尝试根本原因分析时分离责任。由于单个请求可能会触及许多小程序来生成响应，因此很难解释瓶颈或性能变化的来源。为了提供有关每个组件如何导致延迟和处理开销的更好信息，出现了一种称为分布式跟踪的技术。

分布式跟踪是一种检测系统的方法，通过向每个组件添加代码来阐明处理服务时的请求处理。每个请求都在您的基础架构边缘给出一个唯一标识符，该标识符在任务遍历您的基础结构时传递。然后，每个服务都使用此ID来报告错误，或记录接收请求时间以及何时将其移交给下一阶段的时间戳。通过使用这个ID聚合来自组件的报告，可以通过您的基础架构跟踪具有准确时序数据的详细路径。

此方法可用于了解在流程的每个部分上花费了多少时间，并清楚地识别出任何严重的延迟增加。这种额外的工具是一种使度量收集，适应大量处理组件的方法。当在x轴上以时间可视地映射时，生成的内容显示不同阶段之间的关系，每个进程运行的时间以及必须并行运行的事件之间的依赖关系。这对于了解如何改进系统以及如何花费时间非常有用。

# 提高分布式系统的运营响应能力 #

我们已经讨论了分布式体系结构如何使错误原因分析和操作清晰度变得难以实现。在许多情况下，改变人类对问题的回应和调查方式是这些含糊不清的答案的一部分。设置工具以便以有条理的方式分析情况的方式公开信息，可以帮助分类可用的多个数据层。在本节中，我们将讨论在解决大型分布式环境中的问题时为成功做好准备的方法。

## 为每一层设置四个黄金信号的警报 ##

确保您可以响应系统中的问题的第一步是了解它们何时发生。在我们的基础架构和应用程序收集指标的指南中，我们介绍了Google SRE团队确定的四个黄金信号监控指标，这些指标是最重要的跟踪指标。这四个信号是：

*  延迟
 *  流量
 *  错误率
 *  饱和度

在检测系统时，这些仍然是最佳起点，但高分布式系统通常会增加必须监视的层数。底层基础架构，业务流程层和工作层都需要强大的监控功能，并设置周到的警报以识别重要的变化。警报条件可能在复杂性上增加，以考虑平台内固有的短暂元素。

## 获得完整的图像 ##

一旦您的系统发现异常情况并通知您的员工，您的团队就需要开始收集数据。在继续执行此步骤之前，他们应该了解受影响的组件，事件发生的时间以及触发的特定警报条件。

开始理解事件范围的最有用方法是从高层开始。通过检查收集和概括整个系统信息的仪表板和可视化来开始调查。这可以帮助您快速识别相关因素并了解面临的面向用户的影响。在此过程中，您应该能够覆盖来自不同组件和主机的信息。

此阶段的目标是开始创建项目的精神或物理清单，以更详细地检查并开始优先调查。如果您可以识别遍历不同层的一系列相关问题，则最低层应该优先：基础层的修复通常可以解决更高级别的症状。受影响的系统列表可以作为一个非正式的检查清单，用于在部署缓解措施时验证修复程序。

## 深入研究具体问题 ##

一旦您认为自己拥有合理的事件高级视图，请按优先级顺序深入了解列表中的组件和系统。有关各个单元的详细指标将帮助您将故障路由跟踪到最低负责的资源。在查看更细粒度的仪表板和日志条目时，请参考受影响组件的列表，以尝试进一步了解如何通过系统传播作用。使用微服务，相互依赖的组件的数量意味着问题会更频繁地蔓延到其他服务。

此阶段的重点是隔离负责初始事件的服务，组件或系统，并确定正在发生的具体问题。这可能是新部署的代码，错误的物理基础架构，业务流程层中的错误，或者系统无法正常处理的工作负载变化。诊断正在发生的事情以及为什么允许您发现如何缓解问题并重新获得运营状况。了解解决此问题可能解决其他系统上报告的问题的程度可以帮助您继续确定缓解任务的优先级。

## 减轻解决问题的能力 ##

一旦确定了具体细节，您就可以解决或减轻问题。在许多情况下，通过提供更多资源，回滚或将流量重新路由到备用实现，可能会是一种明显、快速的方法来恢复服务。在这些情况下，解决方案将分为三个阶段：

*  执行操作以解决问题并恢复即时服务
 *  解决潜在问题以重新获得全部功能和运营状况
 *  全面评估失败的原因并实施长期修复以防止再次发生

在许多分布式系统中，冗余和高可用性组件将确保快速恢复服务，但在后台可能需要更多工作来恢复冗余或使系统退出降级状态。您应该使用先前编译的受影响组件列表作为衡量标准来确定您的初始缓解是否可以解决级联服务问题。随着监控系统的复杂性的发展，它还可以通过向配置层发送命令来启动故障单元的新实例或循环出行为不当的单元，从而使这些更全面的恢复过程自动化。

鉴于前两个阶段可能实现自动化，运营团队最重要的工作通常是了解事件的根本原因。从此过程中收集的知识可用于开发新的触发器和策略，以帮助预测未来会发生的情况，并进一步自动化系统的反应。监控软件通常会获得响应每个事件的新功能，以防止新发现的故障情况。对于分布式系统，分布式跟踪，日志条目，时间序列可视化以及最近部署等事件可帮助您重建事件序列并确定可以改进软件和人员流程的位置。

由于大型分布式系统固有的特殊复杂性，将任何重要事件的解决过程视为学习和微调系统的机会非常重要。所涉及的单独组件和通信路径的数量迫使人们严重依赖自动化和工具来帮助管理复杂性。将新方法编入这些组件的响应机制和规则集（以及您的团队遵守的操作策略）是监控系统保持团队管理足迹的最佳方式。

# 结论 #

在本文中，我们讨论了分布式体系结构和微服务设计为监视软件引入的一些特定挑战。构建系统的现代方法打破了传统方法的一些假设，需要不同的方法来处理新的配置环境。我们探讨了当您从单体系统转向越来越依赖于云或基于容器的环境以及高容量网络协调时需要考虑的调整。之后，我们讨论了您的系统架构可能会影响您对事件和解决方案的响应方式的一些方法。

[Link 1]: https://blog.csdn.net/peterwanghao/article/details/82784963
[Link 2]: https://blog.csdn.net/peterwanghao/article/details/82837368
[Link 3]: https://blog.csdn.net/peterwanghao/article/details/82862939