介绍
系统和基础设施监控是各种规模运营团队的核心职责。 业界已经共同开发了许多策略和工具来帮助监控服务器，收集重要数据，以及在不同的环境中对事件和不断变化的情况做出反应。 然而，随着软件方法和基础设施设计的发展，监控必须适应新的挑战，并在相对陌生的领域提供见解。
到目前为止，在本系列中，我们已经讨论了哪些指标，监控和警报以及良好监控系统的质量。 我们讨论了从基础架构和应用程序收集指标以及监控整个基础架构的重要信号。 在我们的最后一篇指南中，我们介绍了如何通过了解各个组件和良好的警报设计的质量来将度量和警报实践化。
在本指南中，我们将介绍高度分布式体系结构和微服务的监视和度量标准收集更改。 云计算，大数据集群和实例编排层的日益普及迫使业务专业人员重新思考如何设计大规模监控，并通过更好的仪器解决独特的问题。 我们将讨论什么使得部署的新模型不同，以及可以采用哪些策略来满足这些新的需求。
高度分布式体系结构创造了什么挑战？
为了对它所监视的系统进行建模和镜像，监视基础设施一直是分布式的。 但是，许多现代开发实践（包括围绕微服务，容器和可互换的短暂计算实例的设计）已经大大改变了监控环境。 在许多情况下，这些进步的核心特征是使监测最困难的因素。 让我们花点时间来看看它们与传统环境有什么不同，以及它们如何影响监控。
工作从底层资源中分离出来
许多系统运行方式的一些最基本的变化是由于软件可以围绕设计的新的抽象层的爆炸式增长。 容器技术已经改变了部署的软件和底层操作系统之间的关系。 部署在容器中的应用程序与通过常规方式部署的应用程序具有不同于外部世界，其他程序和主机操作系统的关系。 内核和网络抽象可能导致对操作环境的不同理解，具体取决于您检查的是哪一层。
通过创建一致的部署策略，这种抽象级别在许多方面非常有帮助，使得在主机之间迁移工作变得更加容易，并且允许开发人员密切控制其应用程序的运行时环境。 然而，这些新功能是以增加复杂性和与为每个进程提供动力的资源之间更为遥远的关系为代价的。
增加基于网络的通信
新的范式之一是越来越依赖内部网络通信来协调和完成任务。 以前，单个应用程序的领域现在可能分散在需要协调和共享信息的许多组件中。 这在通信基础设施和监测方面有一些影响。
首先，由于这些模型是建立在小型，独立服务之间的通信的基础之上的，网络健康变得比以往更加重要。 在传统的，更单一的体系结构中，协调任务，共享信息和组织结果在很大程度上是在具有常规编程逻辑的应用程序或通过相当少量的外部通信完成的。 相比之下，高度分布式应用的逻辑流使用网络进行同步，检查对等体的健康状况并传递信息。 网络运行状况和性能直接影响到以前的功能，这意味着需要进行更密集的监控来保证正确的操作。
虽然网络变得比以往任何时候都更加重要，但由于参与者数量和通信线路的增加，有效监控网络的能力变得越来越具有挑战性。 为了确保相同的功能，不必跟踪几个应用程序之间的交互，而需要在数十，数百或数千个不同点之间进行正确的通信。 除了考虑复杂性之外，流量的增加还会给可用的网络资源带来额外的压力，进一步增加了可靠监控的必要性。
功能和责任分化程度更高
上面，我们提到现代架构倾向于将许多较小的离散组件之间的工作和功能分开。 这些设计可以对监控领域产生直接的影响，因为它们使得清晰度和可理解性特别有价值，但越来越难以捉摸。
需要更强大的工具和仪器来确保良好的工作秩序。 然而，由于完成任务的责任是分散的，并且分散在不同的工作人员（可能在许多不同的物理主机上），所以理解性能问题或错误的责任在何处可能是困难的。 涉及数十个组件的请求和工作单元（其中许多是从可能的候选者池中选择的）可以使请求路径可视化或根本原因分析不切实际地使用传统机制。
短命的和短暂的单位
在适应传统的监测方面进一步的努力是合理地追踪短命的或短暂的单位。 无论关注的单元是云计算实例，容器实例还是其他抽象，这些组件通常都违反了传统监控软件所做的一些假设。
例如，为了区分有问题的被关闭的节点和故意被破坏的实例，监控系统必须比以前需要更加深入地了解您的供应和管理层。 对于许多现代系统来说，这些事件发生得更频繁，所以每次手动调整监控域都是不现实的。 这些设计使得部署环境变得更加迅速，因此监控层必须采取新的策略来保持价值。
许多系统必须面对的一个问题是如何处理来自被破坏的实例的数据。 虽然可能为了适应不断变化的需求而快速调配和撤销工作单元，但是必须决定如何处理与旧实例相关的数据。 数据不一定会立即失去其价值，只是因为底层工人不再可用。 当成千上万的节点每天都会来来往往时，可能很难从短期实例的零碎数据中知道如何最好地构建关于系统整体运行状况的叙述。
需要哪些更改来扩展您的监控？
现在我们已经确定了分布式体系结构和微服务的一些独特挑战，我们可以讨论监视系统可以在这些现实中工作的方式。 其中一些解决方案涉及重新评估和隔离什么是最有价值的不同类型的指标，而其他涉及新的工具或新的方式来了解他们居住的环境。
粒度和采样
服务数量增加导致的总流量增加是需要考虑的最直接的问题之一。 除了由新体系结构引起的转移数量的膨胀之外，监视活动本身可能开始陷入网络并窃取主机资源。 为了更好地处理增加的数量，您可以扩展您的监控基础设施或降低您使用的数据的分辨率。 这两种方法值得关注，但是我们将把重点放在第二个方面，因为它代表了一个更具扩展性和广泛有用的解决方案。
更改数据采样率可以最大限度地减少系统从主机收集的数据量。 抽样是度量标准收集的一个正常部分，表示您为一个度量标准要求新值的频率。 增加采样间隔将减少必须处理的数据量，但也会降低数据的分辨率（详细程度）。 虽然您必须小心并理解您的最低有效解决方案，但是调整数据收集速率可能会对您的系统可以充分提供多少个监视客户端产生深远的影响。
为了减少由较低分辨率导致的信息丢失，一种选择是继续收集主机上的相同频率的数据，但将其编译成更易消化的数字以通过网络传输。 个人计算机可以汇总和平均度量值，并向监测系统发送摘要。 这可以帮助减少网络流量，同时保持准确性，因为仍然考虑大量的数据点。 请注意，这有助于减少数据收集对网络的影响，但本身并不能帮助收集主机内的这些数字。
基于多个单元汇总数据的决策
如上所述，传统系统与现代架构之间的主要区别之一是组件参与处理请求的细分。 在分布式系统和微服务中，通过某种类型的调度或仲裁层，一个工作单元更可能被分配给一组工作人员。 这对您可能围绕监控建立的许多自动化流程有影响。
在使用可交换工作人员池的环境中，健康检查和警报策略的发展会与他们所监控的基础架构之间存在复杂的关系。 对个体工作人员进行健康检查可以有助于自动退役和回收有缺陷的单位。 但是，如果您有大规模的自动化，则单个Web服务器在大型池中出现故障时无关紧要。 系统将自我纠正，以确保只有健康的单位在活动池接收请求。
虽然主机健康检查可以捕捉到有缺陷的单元，但检查池本身更适合警报。 游泳池满足当前工作负载的能力对用户体验的影响大于任何单个工作人员的能力。 根据健康成员的数量，池汇总延迟或池误差率进行的警报可以向操作员通知更难以自动减轻并更可能影响用户的问题。
与供应层集成
一般来说，分布式系统中的监控层需要对部署环境和配置机制有更全面的了解。 自动化的生命周期管理变得非常有价值，因为这些体系结构中涉及到的单个单元的数量。 无论这些单元是否为原始容器，编排框架中的容器或云环境中的计算节点，都存在一个管理层，用于公开健康信息并接受缩放和响应事件的命令。
在场数量增加了失败的统计可能性。 在所有其他因素相同的情况下，这需要更多的人为干预来应对和缓解这些问题。 由于监控系统负责识别故障和服务降级，如果它能够挂接到平台的控制界面上，就可以缓解这些问题中的一大类问题。 由监视软件触发的即时自动响应可以帮助维护系统的运行状况。
监控系统和部署平台之间的这种密切关系在其他体系结构中不一定是必需的或共同的。 但是自动化分布式系统的目标是自我调节，能够根据预先配置的规则和观察状态进行调整和调整。 在这种情况下，监控系统在控制环境和决定何时采取行动方面起着核心作用。
监控系统必须具备供应层知识的另一个原因是处理短暂事件的副作用。 在工作实例中频繁更换的环境中，监控系统依靠旁道的信息来了解何时行动是有意的。 例如，当服务器被操作员有意破坏的时候，可以从供应器读取API事件的系统可以做出不同的反应，而不是服务器突然变得没有响应而没有关联的事件。 即使底层基础架构可能经常更改，区分这些事件也可以帮助您的监控保持有用，准确和可靠。
分布式追踪
高度分布式工作负载最具挑战性的一个方面是理解不同组件之间的相互作用，并在尝试根本原因分析时分离责任。 由于单个请求可能会触及数十个小程序来生成响应，因此可能难以解释瓶颈或性能变化的起源。 为了提供关于每个组件如何导致延迟和处理开销的更好的信息，已经出现了称为分布式跟踪的技术。
分布式跟踪是一种测试系统的方法，通过向每个组件添加代码来照亮处理请求的过程。 每个请求在您的基础设施边缘都有一个唯一的标识符，随着任务遍历您的基础设施而传递。 然后，每个服务都使用此ID来报告第一次看到请求时的错误和时间戳，以及何时将其递交给下一阶段。 通过使用请求ID汇总来自组件的报告，可以通过基础设施追踪具有准确计时数据的详细路径。
这个方法可以用来理解在一个过程的每个部分花了多少时间，并且清楚地识别任何严重的延迟增加。 这种额外的工具是将度量收集适配到大量处理组件的一种方法。 当在x轴上以可视方式随时间映射时，结果显示将显示不同阶段之间的关系，每个进程运行多长时间以及必须并行运行的事件之间的依赖关系。 这对于理解如何改进系统以及如何花费时间非常有用。
提高分布式系统的操作响应性
我们已经讨论了分布式体系结构如何进行根本原因分析以及难以实现操作清晰度。 在许多情况下，改变人类回应和调查问题的方式是解决这些歧义的一部分。 设置工具以公开信息的方式，使您能够有条不紊地分析情况，可以帮助对可用的多层数据进行排序。 在本节中，我们将讨论如何在大型分布式环境中排除故障时自行成功的方法。
为每个层上的四个金色信号设置警报
确保您可以对系统中的问题做出反应的第一步是了解它们何时发生。 在我们关于从您的基础架构和应用程序收集指标的指南中，我们介绍了Google SRE团队确定的四个黄金信号监控指标，这些指标是最重要的跟踪指标。 四个信号是：
- 潜伏
- 交通
- 错误率
- 饱和
在测试系统时，这些仍然是最好的开始，但是对于高度分布式的系统来说，通常需要监视的层数是增加的。 底层基础架构，编排平面和工作层都需要强大的监控功能，并设置周密的警报来识别重要的变化。 警报条件的复杂性可能会增加，以说明平台中固有的短暂因素。
获取完整的图片
一旦您的系统发现异常并通知您的员工，您的团队就需要开始收集数据。 在继续这一步之前，他们应该了解哪些组件受到影响，事件何时开始以及触发了哪些特定的警报条件。
开始了解事件范围的最有用的方法是从高层开始。 通过检查仪表板和可视化来开始调查，收集和整理系统中的信息。 这可以帮助您快速识别相关因素，并了解直接面向用户的影响。 在此过程中，您应该能够覆盖来自不同组件和主机的信息。
这个阶段的目标是开始创建一个物品的心理或实体清单，更详细地检查，并开始优先考虑你的调查。 如果您可以确定一系列遍历不同层次的相关问题，则应该优先考虑最底层：对基础层的修复通常可以解决更高层次上的症状。 受影响的系统列表可以作为非正式的地点清单，以便稍后在部署缓解时验证修复。
深入研究具体问题
一旦您觉得您对事件具有合理的高级观点，请按优先顺序深入了解列表中组件和系统的更多详细信息。 有关各个单位的详细指标将帮助您将故障的路线追踪到最低的责任资源。 在查看更细粒度的仪表板和日志条目时，请参考受影响组件的列表以尝试进一步了解副作用是如何通过系统传播的。 使用微服务，相互依赖的组件数量意味着问题更频繁地蔓延到其他服务。
这个阶段的重点是隔离负责初始事件的服务，组件或系统，并确定发生了什么特定的问题。 这可能是新部署的代码，错误的物理基础设施，编排层中的错误或错误，或系统无法正常处理的工作负载更改。 诊断发生了什么，为什么让你发现如何缓解这个问题，并重新获得运营健康。 了解解决此问题的程度可能会解决在其他系统上报告的问题可以帮助您继续优先考虑缓解任务。
缓解问题的解决
一旦确定具体内容，您可以致力于解决或缓解问题。 在很多情况下，通过提供更多资源，回滚或将流量重新路由到其他实施方式，可能会有一种明显的，快速的方式来恢复服务。 在这些情况下，决议将分为三个阶段：
- 执行操作来解决问题并恢复即时服务
- 解决潜在的问题，重新获得全面的功能和运行健康
- 充分评估失败的原因并实施长期修复以防止再次发生
在许多分布式系统中，冗余和高度可用的组件将确保服务快速恢复，尽管在后台可能需要更多的工作来恢复冗余或使系统退出降级状态。 您应该使用先前编译的受影响组件的列表作为度量标准，以确定您的初始缓解是否解决了级联服务问题。 随着监控系统的复杂性的发展，它也可以通过发送命令到配置层来自动执行一些更完善的恢复过程，以提出失败单元的新实例或者循环出错的单元。
鉴于前两个阶段的自动化可能性，运营团队最重要的工作是经常了解事件的根源。 从这个过程中收集的知识可以用来开发新的触发器和政策，以帮助预测未来的事件，并进一步自动化系统的反应。 监控软件通常会针对每个事件获得新的功能，以防范新发现的故障情况。 对于分布式系统，分布式跟踪，日志条目，时间序列可视化以及近期部署等事件可帮助您重新构建事件序列，并确定软件和人员流程在哪里可以改进。
由于大型分布式系统固有的特殊复杂性，将任何重大事件的解决过程作为学习和微调系统的机会是很重要的。 涉及的独立组件和通信路径的数量迫使人们过分依赖自动化和工具来帮助管理复杂性。 将新课程编入这些组件的响应机制和规则集（以及您的团队遵守的操作策略）是您的监控系统最好的方法来保持团队的管理足迹。
结论
在本指南中，我们谈到了分布式架构和微服务设计可能为监控和可见性软件带来的一些具体挑战。 构建系统的现代方法打破了传统方法的一些假设，需要不同的方法来处理新的配置环境。 我们研究了从整体式系统转向日益依赖短暂，云端或容器工作人员以及大量网络协调的情况下需要考虑的调整。 之后，我们讨论了一些您的系统架构可能会影响您对事件和解决方案做出响应的方式。
