指标、监控和警报简介
介绍
了解基础架构和系统的状态对于确保服务的可靠性和稳定性至关重要。 有关部署的运行状况和性能的信息不仅可以帮助您的团队对问题做出反应，还可以让他们放心地进行更改。 获得这种洞察力的最佳方法之一是使用强大的监控系统，该系统可以收集指标、可视化数据并在出现问题时向操作员发出警报。
在本指南中，我们将讨论什么是指标、监控和警报。 我们将讨论它们为何重要、它们提供的机会类型以及您可能希望跟踪的数据类型。 在此过程中，我们将介绍一些关键术语，并以您在探索该领域时可能遇到的其他一些术语的简短词汇表结尾。
什么是指标、监控和警报？
指标、监控和警报都是相互关联的概念，它们共同构成了监控系统的基础。 他们能够提供对系统运行状况的可见性，帮助您了解使用或行为的趋势，并了解您所做更改的影响。 如果指标超出您的预期范围，这些系统可以发送通知以提示操作员查看，然后可以帮助显示信息以帮助确定可能的原因。
在本节中，我们将了解这些单独的概念以及它们如何组合在一起。
什么是指标，我们为什么要收集它们？
指标表示可以在整个系统中观察和收集的资源使用或行为的原始测量值。 这些可能是操作系统提供的低级使用摘要，也可能是与组件的特定功能或工作相关的高级数据类型，例如每秒处理的请求数或 Web 服务器池中的成员资格。 一些指标与总容量相关，而其他指标则表示为指示组件“忙碌”的比率。
通常，最简单的指标是操作系统已经公开的指标，用于表示底层物理资源的使用情况。 有关磁盘空间、CPU 负载、交换使用情况等的数据。 已经可用，立即提供价值，并且无需太多额外工作即可转发到监控系统。 许多 Web 服务器、数据库服务器和其他软件也提供自己的指标，这些指标也可以向前传递。
对于其他组件，尤其是您自己的应用程序，您可能必须添加代码或接口来公开您关心的指标。 收集和公开指标有时称为将 instrumentation 添加到您的服务。
指标很有用，因为它们可以深入了解系统的行为和健康状况，尤其是在汇总分析时。 它们代表您的监控系统使用的原材料，用于构建环境的整体视图、自动响应变化并在需要时提醒人类。 指标是用于了解历史趋势、关联各种因素以及衡量性能、消耗或错误率变化的基本值。
什么是监控？
虽然指标代表系统中的数据，但监控是收集、汇总和分析这些值以提高对组件特征和行为的认识的过程。 来自环境各个部分的数据被收集到 监控系统 中，该系统负责存储、聚合、可视化，并在值满足特定要求时启动自动响应。
一般来说，指标和监控之间的差异反映了数据和信息之间的差异。 数据由未经处理的原始事实组成，而信息是通过分析和组织数据以构建提供价值的上下文而产生的。 监控获取度量数据，对其进行聚合，并以各种方式呈现它，使人们能够从单个片段的集合中提取洞察力。
监控系统完成了许多相关的功能。 他们的首要职责是接受和存储传入和历史数据。 虽然代表当前时间点的值很有用，但查看与过去值相关的这些数字以提供有关变化和趋势的背景信息几乎总是更有帮助。 这意味着监控系统应该能够管理一段时间内的数据，这可能涉及采样或汇总旧数据。
其次，监控系统通常提供数据的可视化。 虽然指标可以显示和理解为单个值或表格，但当信息以视觉上有意义的方式组织时，人类更善于识别趋势和理解组件如何组合在一起。 监控系统通常用可配置的图表和仪表板来表示他们测量的组件。 这使得通过浏览显示器可以了解复杂变量的相互作用或系统内的变化。
监控系统提供的另一个功能是组织和关联来自各种输入的数据。 为了使指标有用，管理员需要能够识别不同资源之间和服务器组之间的模式。 例如，如果应用程序遇到错误率峰值，管理员应该能够使用监控系统来发现该事件是否与相关资源的容量耗尽同时发生。
最后，监控系统通常用作定义和激活警报的平台，我们将在下面讨论。
什么是警报？
警报是监控系统的响应组件，它根据度量值的变化执行操作。 警报定义由两部分组成：基于度量的条件或阈值，以及当值超出可接受条件时执行的操作。
虽然监控系统对于主动解释和调查非常有用，但完整监控系统的主要好处之一是让管理员脱离系统。 警报允许您定义对主动管理有意义的情况，同时依靠软件的被动监控来观察不断变化的情况。
虽然通知责任方是最常见的警报操作，但也可以根据阈值违规触发一些程序化响应。 例如，指示您需要更多 CPU 来处理当前负载的警报可以使用自动扩展应用程序该层的脚本来响应。 虽然这不是严格意义上的警报，因为它不会导致通知，但通常也可以使用相同的监视系统机制来启动这些进程。
但是，警报的主要目的仍然是引起人们对系统当前状态的关注。 自动响应是确保仅在需要知识渊博的人考虑的情况下才触发通知的重要机制。 警报本身应包含有关问题的信息以及去哪里查找其他信息。 然后，响应警报的个人可以使用监控系统和相关工具（如日志文件）来调查问题的原因并实施缓解策略。
即使是中等复杂性的基础设施也需要区分警报严重性，以便可以使用适合问题规模的方法通知负责的团队或个人。 例如，存储利用率的提高可能需要工作票或电子邮件，而面向客户的错误率或无响应率的增加可能需要向值班人员发送页面。
跟踪什么类型的信息很重要？
随着基础设施的发展，您监控的值类型和跟踪的信息可能会发生变化。 由于系统通常是分层运行的，更复杂的层建立在更原始的基础设施之上，因此在规划监控策略时考虑这些不同级别的可用指标可能很有用。
基于主机的指标
原始指标层次结构的底部是基于主机的指标。 这些将是评估单个机器的健康或性能所涉及的任何事情，暂时不考虑其应用程序堆栈和服务。 这些主要包括操作系统或硬件的使用或性能，例如：
- 中央处理器
- 记忆
- 磁盘空间
- 流程
这些可以让您了解可能影响单台计算机保持稳定或执行工作的能力的因素。
应用程序指标
您可能想要查看的下一类指标是应用程序指标。 这些是与依赖于主机级资源（如服务或应用程序）的处理或工作单元有关的指标。 要查看的具体指标类型取决于服务提供什么、它具有什么依赖项以及它与哪些其他组件交互。 此级别的指标是应用程序运行状况、性能或负载的指标：
- 错误率和成功率
- 服务失败和重启
- 响应的性能和延迟
- 资源使用
这些指标有助于确定应用程序是否正常运行且效率高。
网络和连接指标
对于大多数类型的基础设施，网络和连通性指标将是另一个值得探索的数据集。 这些是对外可用性的重要衡量标准，但对于确保跨多台机器的任何系统的其他机器可以访问服务也是必不可少的。 与我们迄今为止讨论的其他指标一样，应通过以下方面检查网络的整体功能正确性和提供必要性能的能力：
- 连接性
- 错误率和丢包率
- 潜伏
- 带宽利用率
监控网络层可以帮助您提高内部和外部服务的可用性和响应能力。
服务器池指标
在处理水平扩展的基础架构时，您需要为其添加指标的另一层基础架构是服务器池。 虽然有关单个服务器的指标很有用，但在规模上，服务更好地表示为一组机器执行工作和充分响应请求的能力。 这种类型的指标在许多方面只是应用程序和服务器指标的更高级别的外推，但这种情况下的资源是同质服务器而不是机器级组件。 您可能要跟踪的一些数据是：
- 资源池使用情况
- 缩放调整指标
- 降级的实例
收集汇总服务器集合运行状况的数据对于了解系统处理负载和响应更改的实际能力非常重要。
外部依赖度量
您可能希望添加到系统的其他指标是与外部依赖项相关的指标。 通常，服务提供状态页面或 API 来发现服务中断，但在您自己的系统中跟踪这些以及您与服务的实际交互可以帮助您识别可能影响您的运营的供应商问题。 可能适用于此级别跟踪的一些项目是：
- 服务状态和可用性
- 成功率和错误率
- 运行率和运营成本
- 资源枯竭
还有许多其他类型的指标有助于收集。 以不同的重点对最重要的信息进行概念化可以帮助您确定对预测或识别问题最有用的指标。 请记住，较高级别上最有价值的指标可能是较低层提供的资源。
影响您选择监控的因素
为了安心，在理想的世界中，您将从一开始就跟踪与您的系统相关的所有内容，以防某天某天可能与您相关。 然而，这可能是不可能的，甚至是不可取的，原因有很多。
可能会影响您选择收集和采取行动的一些因素是：
- 可用于跟踪的资源：根据您的人力资源、基础设施和预算，您必须将跟踪的范围限制在您能够负担得起的实施和合理管理的范围内。
- 应用程序的复杂性和目的：应用程序或系统的复杂性会对您选择跟踪的内容产生很大影响。 对于某些软件来说可能是关键任务的项目在其他软件中可能根本不重要。
- 部署环境：虽然健壮的监控对于生产系统来说是最重要的，但暂存和测试系统也可以从监控中受益，尽管在严重性、粒度和测量的整体指标方面可能存在差异。
- 指标有用的可能性：影响某事物是否被测量的最重要因素之一是它在未来提供帮助的潜力。 跟踪的每个附加指标都会增加系统的复杂性并占用资源。 数据的必要性也会随着时间而改变，需要定期重新评估。
- 稳定性有多重要：简而言之，稳定性和正常运行时间可能不是某些类型的个人或早期项目的优先事项。
影响您决策的因素将取决于您的可用资源、项目的成熟度以及您需要的服务水平。
度量、监控和警报系统的重要品质
虽然每个监控应用程序或服务都有其优点和缺点，但最佳选择通常具有一些重要的品质。 下面是评估监控系统时要寻找的一些更重要的特征。
独立于大多数其他基础设施
一个适当的监控系统最基本的要求之一是在其他服务之外。 虽然有时将服务组合在一起很有用，但监控系统的核心职责、它在诊断问题方面的帮助以及它与被监视系统的关系意味着让您的监控系统能够独立访问非常重要。 您的监控系统将不可避免地对其监控的系统产生一些影响，但您应该尽量减少这种影响，以减少跟踪对性能的影响，并在出现其他系统问题时提高监控的可靠性。
可靠和值得信赖
另一个基本要求是可靠性。 由于监控系统负责收集、存储和提供对高价值信息的访问，因此您可以信任它每天都能正常运行，这一点很重要。 丢失的指标、服务中断和不可靠的警报都会对您有效管理基础架构的能力产生直接的有害影响。 这不仅适用于核心软件的可靠性，也适用于您启用的配置，因为不准确警报等错误会导致对系统失去信任。
易于使用的摘要和详细视图
显示高级摘要并按需要求提供更多详细信息的能力是确保指标数据对人类操作员有用和可消费的重要功能。 设计以一种立即可理解的方式呈现最常查看的数据的仪表板可以帮助用户一目了然地了解系统状态。 可以为不同的工作职能或感兴趣的领域创建许多不同的仪表板视图。
同样重要的是能够从摘要显示中向下钻取以显示与当前任务最相关的信息。 动态调整图表的比例、切换不必要的指标以及覆盖来自多个系统的信息对于使该工具以交互方式对调查或根本原因分析有用是必不可少的。
维护历史数据的有效策略
当监控系统具有丰富的历史数据，可以帮助建立长期趋势、模式和一致性时，它是最有用的。 虽然理想情况下，所有信息都将无限期地保留在其原始粒度中，但成本和资源限制有时可能需要以降低的分辨率存储旧数据。 监控系统可以灵活地处理全粒度和采样格式的数据，为如何处理不断增加的数据量提供了更广泛的选择。
一个有用的相关功能是能够轻松导入现有数据集。 如果降低历史指标的信息密度不是一个有吸引力的选择，那么将旧数据卸载到长期存储解决方案可能是一个更好的选择。 在这种情况下，您不需要在系统中维护旧数据，但是当您希望分析或使用它时，您需要能够批量重新加载它。
能够关联来自不同来源的因素
监控系统负责提供整个基础架构的整体视图，因此它需要能够显示相关信息，即使它来自不同的系统或具有不同的特征。 管理员应该能够随意将来自其系统不同部分的信息粘合在一起，以了解整个基础架构中的潜在交互和整体状态。 确保跨系统配置时间同步是能够可靠地关联来自不同系统的数据的先决条件。
轻松开始跟踪新指标或基础设施
为了让您的监控系统准确地代表您的系统，您需要能够随着机器和基础设施的变化进行调整。 添加额外机器时的最小摩擦将帮助您做到这一点。 同样重要的是能够轻松移除退役机器，而不会破坏与它们相关的收集数据。 系统应使这些操作尽可能简单，以鼓励将监控设置为实例供应或停用过程的一部分。
一个重要的相关能力是可以轻松设置监控系统以跟踪全新的指标。 这取决于核心监控配置中定义指标的方式以及可用于将指标数据发送到系统的机制的种类和质量。 定义新指标通常比添加额外的机器更复杂，但降低添加或调整指标的复杂性将有助于您的团队在适当的时间范围内响应不断变化的需求。
灵活而强大的警报
要评估的监控系统最重要的方面之一是其警报能力。 除了非常严格的可靠性要求外，警报系统还需要足够灵活，能够通过多种媒介通知操作员，并且足够强大，能够组合出深思熟虑、可操作的通知触发器。 许多系统通过提供与现有寻呼服务或信使应用程序的集成来推迟向其他方实际传递通知的责任。 这最大限度地减少了警报功能的责任，并且通常提供更灵活的选项，因为插件只需要使用外部 API。
然而，监控系统不能推迟的部分是定义警报参数。 警报是根据超出可接受范围的值定义的，但定义可能需要一些细微差别，以避免过度警报。 例如，瞬时峰值通常不是问题，但持续升高的负载可能需要操作员注意。 能够清楚地定义警报的参数是组成一组强大、可信赖的警报条件的要求。
附加术语
当您探索监控生态系统时，您将开始遇到一组共享术语，这些术语经常用于讨论监控系统的特征、正在处理的数据以及需要考虑的不同权衡。 虽然并非详尽无遗，但下面的列表可以帮助您了解一些您最有可能遇到的术语。
- 可观察性：虽然没有严格定义，但可观察性是一个通用术语，用于描述与提高系统意识和可见性相关的过程和技术。 这可以包括监控、度量、可视化、跟踪和日志分析。
- Resource：在监控和软件系统的上下文中，资源是任何可耗尽或有限的依赖关系。 根据所讨论的系统的一部分，被视为资源的内容可能会有很大差异。
- Latency：延迟是衡量完成一个动作所花费的时间。 根据组件的不同，这可以是处理、响应或旅行时间的度量。
- Throughput：吞吐量表示系统可以处理的最大处理或遍历速率。 这可能取决于软件或硬件设计。 理论吞吐量和实际观察到的吞吐量之间通常存在重要区别。
- Performance：性能是衡量系统完成工作效率的一般指标。 性能是一个总称，通常包含吞吐量、延迟或资源消耗等工作因素。
- Saturation：饱和度是使用容量的量度。 完全饱和表示当前正在使用 100% of 容量。
- 可视化：可视化是以允许通过图形或图表快速、直观地解释的格式呈现度量数据的过程。
- 日志聚合：日志聚合是编译、组织和索引日志文件的行为，以便于管理、搜索和分析。 虽然与监控分开，但聚合日志可以与监控系统结合使用，以识别原因并调查故障。
- 数据点：数据点是单个度量的单个测量值。
- 数据集：数据集是度量的数据点的集合。
- Units：单位是测量值的上下文。 单位定义了测量的幅度、范围或数量，以了解程度并允许进行比较。
- 百分比单位：百分比单位是作为有限整体的一部分进行的测量。 百分比单位表示一个值在可能的总量中占多少。
- Rate Units：速率单位表示一个指标在恒定时间段内的大小。
- 时间序列：时间序列数据是代表随时间变化的一系列数据点。 大多数指标最好用时间序列来表示，因为单个数据点通常表示特定时间的值，并且生成的点序列用于显示随时间的变化。
- 采样率：采样率是衡量一个代表性数据点的采集频率，而不是连续采集。 更高的采样率更准确地代表了测量的行为，但需要更多的资源来处理额外的数据点。
- Resolution：分辨率是指构成数据集的数据点的密度。 在同一时间范围内具有更高分辨率的集合表示更高的采样率和更细粒度的相同行为视图。
- Instrumentation：Instrumentation 是跟踪软件行为和性能的能力。 这是通过向软件添加代码和配置以输出数据来实现的，然后监控系统可以使用这些数据。
- 观察者效应：观察者效应是监测系统本身对被观察现象的影响。 由于监控占用资源，因此衡量行为和绩效的行为将改变所产生的价值。 监控系统寻求避免增加不必要的开销以尽量减少这种影响。
- 过度监控：当配置的指标和警报的数量与其有用性成反比时，就会发生过度监控。 过度监控可能会给基础架构造成压力，使查找相关数据变得困难，并导致团队对其监控和警报系统失去信任。
- 警报疲劳：警报疲劳是由于频繁、不可靠或优先级不正确的警报导致的人类对不敏感的反应。 警报疲劳会导致操作员忽略严重的问题，并且通常表明警报条件需要重新评估。
- Threshold：警报时，阈值是可接受值和不可接受值之间的边界，如果超过则触发警报。 警报通常配置为在某个值超过阈值一段时间后触发，以避免针对临时峰值发送警报。
- Quantile：分位数是一个分割点，用于根据数据集的值将数据集分成不同的组。 分位数用于将值放入代表数据群体的“桶”中。 通常，这用于将常见值与异常值区分开来，以更好地理解什么是代表性和极端情况。
- Trend：趋势是一组值所指示的总体方向。 在确定被跟踪组件的一般状态时，趋势比单个值更可靠。
- 白盒监控：白盒监控是一个术语，用于描述依赖于访问被测组件的内部状态的监控。 白盒监控可以提供对系统状态的详细了解，并有助于确定问题的原因。
- 黑盒监控：黑盒监控是通过仅查看其输入、输出和行为来观察系统或组件的外部状态的监控。 这种类型的监控可以与用户的系统体验紧密结合，但对于查找问题原因的用处不大。
结论
收集指标、监控组件和配置警报是设置和管理生产基础架构的重要组成部分。 能够了解系统内正在发生的事情、需要注意哪些资源以及导致减速或中断的原因是非常宝贵的。 虽然设计和实施监控设置可能是一项挑战，但这是一项投资，可以帮助您的团队确定工作的优先级，将监督责任委托给自动化系统，并了解您的基础设施和软件对稳定性和性能的影响.
