介绍
系统和基础设施监控是各种规模的操作团队的核心责任,行业已经集体开发了许多策略和工具,以帮助监控服务器,收集重要数据,并在不同环境中响应事件和变化条件。
迄今为止,在本系列中,我们已经讨论了(https://andsky.com/tech/tutorials/an-introduction-to-metrics-monitoring-and-alerting)和良好监控系统的品质(https://andsky.com/tech/tutorials/gathering-metrics-from-your-infrastructure-and-applications)以及在整个基础设施中监控的重要信号(https://andsky.com/tech/tutorials/gathering-metrics-from-your-infrastructure-and-applications)在我们最后的指南中,我们涵盖了如何(https://andsky.com/tech/tutorials/putting-monitoring-and-alerting-into-practice)通过了解个别组件和良好警报设计的品质(https://andsky.com/tech/tutorials/putting-monitoring-and-alerting-into-practice)来实现(https://andsky.com/tech/tutorials/putting-monitoring-and-alerting-into-practice)的指标和警报。
在本指南中,我们将看看高度分布式架构和微服务的监控和指标收集如何发生变化。云计算、大数据集群和实例管制层的日益普及迫使运营专业人员重新考虑如何在规模上设计监控并通过更好的仪表解决独特问题。
高度分布式架构带来了哪些挑战?
为了模型和反映其监控的系统,监控基础设施一直在被分布一些,但许多现代开发实践,包括围绕微服务,容器和可交换的、平时的计算实例的设计,都极大地改变了监控环境。
工作与底层资源分离
许多系统行为的一些最根本的变化是由于软件可以设计的新抽象层的爆炸。容器技术改变了部署的软件和底层操作系统之间的关系。在容器中部署的应用程序与外部世界,其他程序和主机操作系统的关系不同,而不是通过传统手段部署的应用程序。
这种抽象程度在许多方面是非常有用的,因为它创造了一致的部署策略,使工作在主机之间更容易迁移,并允许开发人员对应用程序的运行时环境进行密切控制。
增加基于网络的通信
新范式的一个共同点是增加对内部网络通信的依赖,以协调和完成任务. 以前是一个应用程序的领域现在可能在需要协调和共享信息的许多组件中传播。
首先,由于这些模型是建立在小型、分散的服务之间的通信基础上,网络健康变得比以往任何时候都更为重要。在传统的、更加单一的架构中,协调任务、共享信息和组织结果在应用程序中,主要是通过定期编程逻辑或比较少量的外部通信实现的。
虽然网络变得比以往任何时候都更关键,但由于参与者数量的增加和通信线路的增加,有效监控能力越来越具有挑战性,而不是跟踪几个应用程序之间的互动,需要数十个,数百个或数千个不同的点之间的正确通信,以确保相同的功能。
功能和责任分布在更大程度上
上面我们提到,现代建筑的趋势是将工作和功能分为许多较小的、分散的组件,这些设计可以对监控景观产生直接影响,因为它们使清晰度和可理解性特别有价值,但越来越难以置信。
需要更强大的工具和仪器来确保良好的工作顺序,但是,由于完成任何特定任务的责任是分裂的,并在不同的工人之间分裂(潜在地在许多不同的物理主机上),理解负有责任的性能问题或错误可能很困难。
短期和短期单位
适应常规监控的进一步斗争是合理地跟踪短期或短期单元,无论关注的单元是云计算实例、容器实例或其他抽象,这些组件往往违反了常规监控软件所作的一些假设。
例如,为了区分一个有问题的下落节点和一个故意被破坏以缩小规模的实例,监控系统必须比以前所需要的更深入地了解您的预算和管理层。
许多系统必须面对的一个问题是如何处理被破坏的实例数据. 虽然工作单元可能会被快速配置和退出,以适应不断变化的需求,但必须做出有关与旧实例相关的数据的决定。 数据不一定会立即失去价值,因为基础工人不再可用。 当每天有数百或数千个节点出现时,很难知道如何从短期实例的碎片化数据中构建一个关于系统整体运行健康的故事。
需要哪些变化来扩展您的监控?
现在我们已经确定了分布式架构和微服务的一些独特挑战,我们可以谈论监控系统可以在这些现实中运作的方式。
颗粒性和样本化
由于服务数量增加而导致的总流量增加是最简单的问题之一。 除了由新架构引起的传输数量膨胀之外,监控活动本身可以开始破坏网络并窃取主机资源。
更改数据采样率可以最大限度地减少系统需要从主机收集的数据量。采样是指数收集的正常部分,它代表了您对指数要求新值的频率。增加采样间隔将减少您需要处理的数据量,同时也减少数据的分辨率(细节级别)。
为了减少由于较低分辨率而导致的信息损失,一种选择是继续以相同的频率收集主机上的数据,但将其编译成更可消化的数字来通过网络传输。 单个计算机可以汇总和平均计量值,并向监控系统发送总结。 这可以帮助减少网络流量,同时保持准确性,因为大量数据点仍然被考虑。
基于从多个单位汇总的数据做出决策
如上所述,传统系统和现代架构之间的主要区别因素之一是分解哪些组件参与处理请求。在分布式系统和微服务中,一个工作单位更有可能通过某种类型的计划或仲裁层给一群工人。
在使用可交换工人池的环境中,健康检查和警报政策可以发展成为与他们监控的基础设施的复杂关系。对个别工人的健康检查可以有助于自动解除操作并回收有缺陷的单位。但是,如果您有自动化,在规模上,如果一个单一的Web服务器失败在一个大池子里,这并不重要。
虽然主机健康检查可以捕捉缺陷的单位,但健康检查池本身更适合警告。池的能力满足当前工作负荷对用户体验有更大的影响,而不是任何个别工人的能力。
与提供层的集成
一般来说,分布式系统中的监控层需要对部署环境和提供机制有更全面的了解。自动化生命周期管理变得非常有价值,因为这些架构中涉及的个别单位的数量。
游戏中的部件数量增加了失败的统计概率. 所有其他因素都是一样的,这将需要更多的人类干预来应对和缓解这些问题。 由于监控系统负责识别失败和服务退化,如果它可以连接到平台的控制接口,它可以缓解这些问题的大类。 监控软件引发的即时和自动响应可以帮助维持系统的操作健康。
监控系统与部署平台之间的这种密切关系在其他架构中并不一定是必需的或常见的,但自动分布式系统的目标是自我调节,能够根据预先配置的规则和观察状态进行扩展和调整。
在工作实例中频繁流通的环境中,监控系统依赖于侧面渠道的信息来了解何时行动是故意的,例如,可以读取提供商的API事件的系统在服务器被操作员故意摧毁时会做出不同的反应,而不是当服务器突然无法响应没有相关事件时。
分布式追踪
高度分布式工作负载的最具挑战性的方面之一是理解不同组件之间的相互作用,并在尝试根源原因分析时分离责任。由于单个请求可能会触及数十个小程序来产生响应,因此很难解释瓶颈或性能变化的起源。
分布式跟踪是通过将代码添加到每个组件,以照亮请求处理,因为它通过您的服务。每个请求在您的基础设施边缘提供了一个独特的标识符,该标识符在任务穿越您的基础设施时传递给您的基础设施。然后,每个服务使用此标识符来报告错误和首次看到请求和传递到下一个阶段的时刻标识符。
这种方法可以用来理解过程的每个部分花费了多少时间,并清楚地识别延迟的严重增加。这个额外的仪表是将指数集合适应大量的处理组件的一种方式。当视觉地图与x轴上的时间进行时,结果显示了不同阶段之间的关系,每个过程运行了多长时间,以及必须并行运行的事件之间的依赖关系。
提高分布式系统的操作响应能力
我们讨论了分布式架构如何使根因分析和操作清晰度难以实现。在许多情况下,改变人类响应和调查问题的方式是这些模糊性的答案的一部分。设置工具以以一种方式暴露信息,使您能够有方法地分析情况,有助于通过可用的许多数据层进行分类。
设置每个层上的四个黄金信号警报
确保您能够对系统中的问题做出回应的第一步是知道它们何时发生,在我们关于 从基础设施和应用程序中收集指标的指南中,我们引入了四个黄金信号 - 监控指标,这些指标由Google SRE团队确定为最重要的可追踪。
- 延迟
- 流量
- 错误率
- 饱和度
这些仍然是开始仪表系统时的最佳场所,但必须监视的层次数量通常在高度分布的系统中增加。底层基础设施、编排平面和工作层都需要强有力的监控,并设置有思维的警报来识别重要的变化。
获得完整的图像
一旦您的系统确定了异常并通知您的员工,您的团队需要开始收集数据。
开始了解事件的范围最有用的方法是从一个高级别开始。 通过检查仪表板和可视化来开始调查,这些仪表板收集和概括来自您的系统的信息。 这可以帮助您快速识别相关因素并了解用户的直接影响。
这个阶段的目标是开始创建一个精神或物理库存的项目,以便更详细地检查并开始优先考虑你的调查. 如果你可以识别一个链接的相关问题,通过不同的层面,最低层应占据优先地位:修复到基础层往往解决症状在更高的层面。
为具体问题钻井下来
一旦您觉得您对事件有合理的高层次的看法,请在优先顺序列表中的组件和系统中查找更多细节。关于单个单位的详细指标将帮助您追踪失败的路线到最低的负责任资源。 同时,在查看更多精细的仪表板和日志条目时,请参考受影响组件的列表,以进一步了解系统中如何传播副作用。
这个阶段的重点是隔离对初始事件负责的服务、组件或系统,并确定发生了哪些具体问题。这可能是新部署的代码、有缺陷的物理基础设施、编排层中的错误或错误,或者系统无法顺利处理的工作负载的变化。诊断发生了什么以及为什么会让你发现如何减轻问题并恢复运行健康。了解解决这个问题可能在其他系统中解决的问题的程度可以帮助你继续优先考虑减缓任务。
缓解解决问题
在许多情况下,可能有一个明显的,快速的方式来恢复服务,通过提供更多的资源,滚动回来,或重定向流量到替代实现。
- 执行操作以处理问题并恢复即时服务
- 解决潜在问题以恢复完整的功能和运行健康
- 充分评估故障的原因并实施长期修复以防止复发
在许多分布式系统中,冗余和高可用性组件将确保服务快速恢复,尽管在背景下可能需要更多的工作来恢复冗余或使系统脱离退化状态。您应该使用先前编制的受影响组件列表作为测量棒来确定您的初始减缓是否解决了流动性服务问题。随着监控系统的复杂性发展,它也可能能够通过将命令发送到供应层来自动化一些这些更全面的恢复流程,以产生新的失败单元或循环出错误的单元。
鉴于自动化在前两个阶段是可能的,操作团队最重要的工作往往是了解事件的根源原因。从这个过程中获得的知识可以用来开发新的触发器和政策,以帮助预测未来的事件,并进一步自动化系统的反应。监控软件通常在响应每个事件时获得新的功能,以防范新发现的故障场景。
由于大型分布式系统中固有的特殊复杂性,因此,将任何重大事件的解决过程视为学习和调整系统的机会。涉及的独立组件和通讯路径数量迫使人们依赖自动化和工具来帮助管理复杂性,将新的教训编码到这些组件的响应机制和规则集(以及您的团队遵循的运营政策)是监控系统保持团队管理足迹的最佳方法。
结论
在本指南中,我们谈到了分布式架构和微服务设计可以引入监控和可见性软件的一些具体挑战。现代构建系统的方式破坏了传统方法的一些假设,需要不同的方法来处理新配置环境。我们探索了您需要考虑的调整,因为您从单一系统转向那些越来越依赖于以时空、云或集装箱为基础的工人和高容量网络协调的系统。