监控分布式和微服务部署

介绍

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

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

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

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

为了对其监视的系统进行建模和镜像，监控基础设施总是有些分散。然而，许多现代开发实践——包括围绕微服务、容器和可互换的临时计算实例的设计——已经极大地改变了监控环境。在许多情况下，这些进步的核心特征正是使监控变得最困难的因素。让我们花点时间看看它们与传统环境的一些不同之处，以及它们如何影响监控。

工作与底层资源脱钩

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

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

基于网络的通信增加

较新范式的一个共同点是越来越依赖内部网络通信来协调和完成任务。以前单个应用程序的域现在可能分布在需要协调和共享信息的许多组件之间。这在通信基础设施和监控方面有一些影响。

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

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

更大程度地划分功能和责任

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

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

短命和短暂的单位

适应传统监控的进一步努力是明智地跟踪短期或短暂的单元。无论关注的单元是云计算实例、容器实例还是其他抽象，这些组件经常违反传统监控软件所做的一些假设。

例如，为了区分有问题的宕机节点和故意销毁以缩减规模的实例，监控系统必须比以前更深入地了解您的供应和管理层。对于许多现代系统，这些事件发生的频率要高得多，因此每次手动调整监控域是不切实际的。这些设计使部署环境变化得更快，因此监控层必须采用新策略才能保持价值。

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

需要进行哪些更改来扩展您的监控？

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

粒度和采样

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

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

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

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

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

在使用可互换工作人员池的环境中，健康检查和警报策略可能会发展为与他们监控的基础设施建立复杂的关系。对单个工人进行健康检查有助于自动退役和回收有缺陷的设备。但是，如果您有大规模的自动化，那么单个 Web 服务器在大型池中出现故障并不重要。系统将自我纠正以确保只有健康的单元在活动池中接收请求。

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

与供应层集成

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

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

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

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

分布式跟踪

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

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

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

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

我们已经讨论了分布式架构如何使根本原因分析和运营清晰度难以实现。在许多情况下，改变人类对问题的反应和调查方式是解决这些歧义的一部分。设置工具以使您能够有条不紊地分析情况的方式公开信息可以帮助对可用的多层数据进行分类。在本节中，我们将讨论在解决大型分布式环境中的问题时为成功做好准备的方法。

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

确保您能够对系统中的问题做出响应的第一步是了解它们何时发生。在我们的从您的基础设施和应用程序中收集指标的指南中，我们介绍了四个黄金信号 - 由 Google SRE 团队确定为最重要的跟踪指标。这四个信号是：

潜伏
交通
错误率
饱和

这些仍然是检测系统的最佳起点，但对于高度分布式系统，必须观察的层数通常会增加。底层基础设施、编排平面和工作层都需要强大的监控，并设置周到的警报来识别重要的变化。警报条件可能会变得复杂，以考虑平台内固有的短暂元素。

获取完整图片

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

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

此阶段的目标是开始创建项目的心理或物理清单，以便更详细地检查并开始优先考虑您的调查。如果您可以确定跨越不同层的一系列相关问题，则应优先考虑最低层：对基础层的修复通常可以解决更高级别的症状。受影响系统的列表可以作为一个非正式的地方清单，以便在以后部署缓解措施时验证修复。

深入研究特定问题

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

此阶段的重点是隔离负责初始事件的服务、组件或系统，并确定正在发生的具体问题。这可能是新部署的代码、有故障的物理基础设施、编排层中的错误或错误，或者系统无法正常处理的工作负载变化。诊断正在发生的事情和原因可以让您发现如何缓解问题并恢复运营健康。了解解决此问题可能会修复其他系统上报告的问题的程度可以帮助您继续确定缓解任务的优先级。

缓解解决问题

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

采取措施解决问题并立即恢复服务
解决根本问题以恢复全部功能和运行状况
全面评估失败的原因并实施长期修复以防止再次发生

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

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

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

结论

在本指南中，我们讨论了分布式架构和微服务设计可能为监控和可见性软件带来的一些特定挑战。构建系统的现代方法打破了传统方法的一些假设，需要不同的方法来处理新的配置环境。我们探讨了当您从单体系统迁移到越来越依赖临时、云或基于容器的工作人员和大容量网络协调的系统时需要考虑的调整。之后，我们讨论了您的系统架构可能会影响您对事件和解决方案的响应方式的一些方式。