度量,监控和警报简介

了解您所运行的基础架构和系统的状态对于确保您的服务的可靠性和稳定性以及您的团队有信心运作的能力至关重要。获得这种洞察力的最好方法之一就是建立一个强大的监测系统。

介绍

了解您的基础架构和系统的状态对于确保您的服务的可靠性和稳定性至关重要。 关于部署的健康状况和性能的信息不仅可以帮助您的团队对问题做出反应,还可以让他们安心地进行更改。 获得这种洞察力的最佳方法之一是建立一个强大的监测系统,收集指标,可视化数据,并在事件似乎被破坏时提醒操作员。

在本指南中,我们将讨论什么指标,监控和警报。 我们将讨论它们为什么重要,它们提供了什么类型的机会,以及您可能希望跟踪的数据类型。 我们将在此介绍一些关键术语,最后以一个简短的词汇表来介绍在探索这个空间时可能遇到的其他术语。

什么是指标,监测和警报?

度量,监控和警报都是相互关联的概念,共同构成了监控系统的基础。 他们能够提供系统健康状况的可视性,帮助您了解使用情况或行为的趋势,并了解您所做的更改的影响。 如果这些指标超出了预期的范围,这些系统可以发送通知来提醒操作员查看,然后可以帮助查看信息以帮助确定可能的原因。

在本节中,我们将看看这些个人概念以及它们如何组合在一起。

什么是衡量指标,为什么我们收集它们?

度量标准代表可以在整个系统中观察和收集的资源使用情况或行为的原始度量。 这些可能是操作系统提供的低级使用情况摘要,也可能是与组件的特定功能或工作相关的更高级别的数据类型,例如每秒提供的请求或Web服务器池中的成员资格。 一些指标是与总容量相关的,而另一些指标是表示组件“繁忙程度”的比率。

开始的最简单的指标通常是您的操作系统已经公开的代表底层物理资源使用情况的指标。 有关磁盘空间,CPU负载,交换使用情况等的数据已经可用,可立即提供价值,并且可以在不需要额外工作的情况下将其转发给监控系统。 许多Web服务器,数据库服务器和其他软件也提供了自己的指标,这些指标也可以向前传递。

对于其他组件,尤其是您自己的应用程序,您可能需要添加代码或接口来公开您关心的指标。 收集和公开度量标准有时被称为向您的服务添加检测工具

度量标准非常有用,因为它们可以深入了解系统的行为和健康状况,特别是在进行总体分析时。 它们代表了您的监控系统使用的原材料,可以全面了解您的环境,自动响应变化,并在需要时提醒人类。 指标是理解历史趋势,关联多种因素,衡量绩效,消费或错误率变化的基本价值。

什么是监测?

指标代表系统中的数据,监控则是收集,汇总和分析这些值的过程,以提高对组件特征和行为的认识。 将来自环境各个部分的数据收集到一个监控系统中 ,该系统负责存储,汇总,可视化以及在值满足特定要求时启动自动化响应。

一般来说,度量和监控之间的差异反映了数据和信息之间的差异。 数据由原始的,未经处理的事实组成,而信息则是通过分析和组织数据来创建,以建立提供价值的上下文。 监控将采集指标数据,汇总数据,并以各种方式呈现,从而使人们从各个作品集合中提取见解。

监控系统完成许多相关的功能。 他们的首要责任是接受和存储传入和历史数据。 虽然表示当前时间点的值是有用的,但是查看这些与过去值相关的数字以提供围绕变化和趋势的上下文几乎总是更有帮助。 这意味着一个监控系统应该能够管理一段时间的数据,这可能涉及对旧数据进行采样或汇总。

其次,监控系统通常提供数据可视化。 虽然度量标准可以被显示和理解为单个的值或表格,但是人们在识别趋势和理解组件如何以一种视觉上有意义的方式进行组织时,能够更好地理解组件。 监控系统通常用可配置的图表和仪表板来表示他们测量的组件。 这样就可以通过查看显示来理解系统内复杂变量或变化的相互作用。

监测系统提供的另一项功能是组织和关联来自各种输入的数据。 要使指标有用,管理员需要能够识别不同资源之间以及跨服务器组的模式。 例如,如果应用程序遇到错误率高峰,管理员应该能够使用监视系统来发现该事件是否与相关资源的容量耗尽一致。

最后,监控系统通常被用作定义和激活警报的平台,我们将在下面讨论。

什么是警报?

警报是监视系统的响应组件,它根据度量值的变化执行操作。 警报定义由两部分组成:基于指标的条件或阈值,以及当值超出可接受条件时执行的操作。

虽然监控系统对于积极的解释和调查是非常有用的,但是完整的监控系统的主要优势之一是让管理员脱离系统。 警报允许您定义有意义的情况以积极管理,同时依靠软件的被动监视来监视变化的情况。

尽管通知责任方是最常见的警报行为,但也可以基于阈值违规触发一些程序性响应。 例如,指示您需要更多CPU来处理当前负载的警报可以使用自动调整应用程序层的脚本来响应。 虽然这不是严格的警报,因为它不会导致通知,但同样的监控系统机制通常也可以用来启动这些过程。

但是,提醒的主要目的仍然是引起人们的注意力,以对您系统的当前状态进行评估。 自动化响应是确保只有在知识丰富的人需要考虑的情况下才触发通知的重要机制。 警报本身应该包含有关什么是错误的信息,以及在哪里可以找到更多的信息。 然后,响应警报的个人可以使用监控系统和相关工具(如日志文件)来调查问题的原因并实施缓解策略。

即使是中度复杂的基础设施也需要区分警报的严重程度,以便可以使用适合问题规模的方法通知负责的团队或个人。 例如,存储利用率的提高可能需要工作票或电子邮件,而面对客户端的错误率或无响应的增加可能需要向呼叫人员发送一个页面。

什么类型的信息是重要的跟踪?

您监控的价值类型和您追踪的信息可能会随着您的基础设施的发展而变化。 由于系统通常以层次结构运行,在更原始的基础架构之上构建更复杂的层,所以在规划监视策略时考虑这些不同层面上的可用指标会很有用。

基于主机的度量

朝向原始度量的层次的底部是基于主机的指示符。 这些将涉及到评估单个机器的健康或性能的任何事情,而忽视其应用程序和服务。 这些主要由操作系统或硬件的使用或性能组成,如:

  • 中央处理器
  • 记忆
  • 磁盘空间
  • 流程

这些可以让你了解可能影响单台计算机保持稳定或执行工作的因素。

应用程序指标

您可能要查看的下一类指标是应用指标。 这些是与处理或工作单元有关的度量,这些单位取决于主机级别的资源,如服务或应用程序。 要查看的特定类型的指标取决于服务提供的内容,它具有的依赖关系以及与之交互的其他组件。 这个级别的度量标准是应用程序的健康状况,性能或负载的指标:

  • 错误和成功率
  • 服务失败并重新启动
  • 性能和响应延迟
  • 资源使用情况

这些指标有助于确定应用程序的运行是否正确有效。

网络和连接度量标准

对于大多数类型的基础设施,网络和连通性指标将是另一个值得探索的数据集。 这些是面向外部可用性的重要标准,但对于确保其他机器可以访问跨越多台机器的任何系统的服务也是至关重要的。 与我们迄今为止讨论的其他指标一样,应该通过以下方面来检查网络的整体功能正确性和提供必要性能的能力:

  • 连接
  • 错误率和数据包丢失
  • 潜伏
  • 带宽利用率

监控您的网络层可以帮助您提高内部和外部服务的可用性和响应能力。

服务器池度量标准

在处理横向扩展的基础架构时,需要添加度量标准的另一层基础架构是服务器池。 尽管关于单个服务器的度量标准是有用的,但是在规模上,服务能够更好地表现为一组机器执行工作并对请求做出充分响应的能力。 这种度量标准在很多方面只是应用程序和服务器度量标准的更高级的外推,但是在这种情况下,资源是同质服务器而不是机器级组件。 您可能想跟踪的一些数据是:

  • 汇集的资源使用情况
  • 调整调整指标
  • 退化的例子

收集总结服务器集合健康状况的数据对于理解系统处理负载和响应变化的实际功能非常重要。

外部依赖性度量

您可能希望添加到系统的其他指标是与外部依赖关系相关的指标。 通常,服务提供状态页面或API来发现服务中断,但是在您自己的系统中跟踪这些服务以及您与服务的实际交互可以帮助您确定提供商可能会影响您的运营的问题。 一些可能适用于跟踪这个级别的项目是:

  • 服务状态和可用性
  • 成功和错误率
  • 运行率和运营成本
  • 资源枯竭

还有许多其他类型的指标可以帮助收集。 在不同关注层次上概念化最重要的信息可以帮助您确定对于预测或识别问题最有用的指标。 请记住,较高层次上最有价值的指标可能是低层提供的资源。

影响您选择监视的因素

为了安心,在一个理想的世界中,您可以从一开始就跟踪与您的系统相关的所有事情,以防某个项目有一天可能与您有关。 然而,这可能是不可能的,甚至不可取的原因有很多。

一些可能影响您选择收集和采取行动的因素是:

  • 可用于追踪的资源 :根据您的人力资源,基础设施和预算,您将不得不将自己追踪的范围限制在可实施和合理管理的范围内。
  • 您的应用程序的复杂性和目的 :您的应用程序或系统的复杂性可能会对您选择跟踪的内容产生重大影响。 某些软件可能对任务至关重要的项目在其他软件中可能并不重要。
  • 部署环境 :尽管强大的监控对于生产系统来说是最重要的,但是分级和测试系统也能从监控中受益,尽管在严重程度,粒度和衡量的整体指标方面可能存在差异。
  • 衡量标准是否有用的可能性 :影响衡量标准的最重要的因素之一是未来可能的帮助。 跟踪的每个附加度量增加了系统的复杂性并占用资源。 数据的必要性也会随着时间而改变,需要定期重新评估。
  • 稳定性如何 :简而言之,稳定性和正常运行时间可能不是某些类型的个人或早期项目的优先事项。

影响您的决定的因素将取决于您的可用资源,项目的成熟度以及您所需的服务级别。

度量,监视和警报系统的重要特性

虽然每个监控应用程序或服务都有其优点和缺点,但最好的选择往往具有一些重要的品质。 以下是评估监控系统时要注意的几个重要特征。

独立于大多数其他基础设施

一个适当的监测系统的最基本的要求之一是其他服务的外部。 虽然将服务组合在一起有时很有用,但是监控系统的核心职责,诊断问题的有用性以及与所监视系统的关系意味着对于您的监控系统是独立可访问的。 您的监控系统将不可避免地对其所监控的系统产生一些影响,但是您应该尽量减少对跟踪对性能的影响,并在发生其他系统问题时提高监控的可靠性。

可靠和可靠

另一个基本要求是可靠性。 由于监控系统负责收集,存储和提供对高价值信息的访问,因此重要的是您可以信任它每天正确运行。 丢弃的指标,服务中断和不可靠的警报都会对您有效管理基础架构的能力产生直接的有害影响。 这不仅适用于核心软件可靠性,还适用于您所启用的配置,因为错误警报等错误会导致系统失去信任。

易于使用摘要和详细视图

能够显示高级摘要并要求更详细的按需查询是确保度量数据对人类操作员有用且可消费的重要特征。 通过设计仪表板,可以立即清晰地显示最常见的数据,可帮助用户一目了然地了解系统状态。 可以为不同的工作职能或感兴趣的领域创建许多不同的仪表板视图。

同样重要的是能够从摘要显示内向下钻取以显示与当前任务最相关的信息。 动态调整图表规模,切换不必要的指标以及覆盖来自多个系统的信息对于使该工具交互式地用于调查或根本原因分析至关重要。

有效的历史数据维护策略

如果监测系统具有丰富的数据历史,可以在长时间内建立趋势,模式和一致性,那么监测系统就是最有用的。 理想情况下,所有信息将以其原始粒度无限期地保留,但成本和资源限制有时可能使旧数据以较低的分辨率存储。 监控系统能够灵活地以全粒度和采样格式处理数据,为如何处理日益增多的数据提供了更广泛的选择。

有用的相关功能是可轻松导入现有数据集。 如果降低历史数据的信息密度并不是一个有吸引力的选择,那么将旧数据卸载到长期存储解决方案可能是更好的选择。 在这种情况下,您不需要在系统中保留较旧的数据,但是当您希望分析或使用它时,需要能够批量重新加载它。

能够关联不同来源的因素

监控系统负责提供整个基础架构的整体视图,因此即使监控系统来自不同的系统或具有不同的特性,也需要能够显示相关信息。 管理员应该能够将他们系统中不同部分的信息粘合在一起,以了解整个基础架构的潜在交互和整体状态。 确保跨系统配置时间同步是能够可靠地关联来自不同系统的数据的先决条件。

轻松开始跟踪新指标或基础设施

为了使您的监控系统成为您系统的准确表示,您需要随着机器和基础设施的变化进行调整。 添加额外的机器时,最小的摩擦力会帮助你做到这一点。 同样重要的是能够容易地移除退役的机器而不破坏与它们相关的收集的数据。 系统应该尽可能简化这些操作,以鼓励将监视作为实例提供或退休过程的一部分。

一个相关的能力是非常重要的,就是监控系统可以很容易地被设置来追踪全新的指标。 这取决于指标在核心监控配置中的定义方式以及可用于将度量数据发送到系统的机制的多样性和质量。 定义新的度量标准通常比添加额外的机器更复杂,但是降低添加或调整度量标准的复杂性将有助于您的团队在适当的时间范围内响应不断变化的需求。

灵活而强大的警报

监测系统评估最重要的方面之一是警报能力。 除了非常严格的可靠性要求之外,警报系统还需要具有足够的灵活性,以便通过多种媒介通知操作员,并且足够强大,从而能够编写周到,可操作的通知触发器。 许多系统通过提供与现有的寻呼服务或信使应用程序的集成来推迟实际向其他方发送通知的责任。 这最大限度地减少了警报功能的责任,通常提供更灵活的选择,因为插件只需要使用外部的API。

然而,监控系统不能推迟的部分是定义告警参数。 警报是根据超出可接受范围的值定义的,但定义可能需要一些细微差别才能避免过度警报。 例如,瞬时尖峰通常不是问题,但持续的高负荷可能需要操作员的注意。 能够清晰地定义警报的参数是组成稳健可靠的警报条件的要求。

附加术语

在您探索监控生态系统时,您将开始遇到一组经常用于讨论监控系统的特性,正在处理的数据以及需要考虑的各种权衡的共享术语。 尽管没有详尽的列表,下面的列表可以帮助您向您介绍一些最有可能遇到的术语。

  • 可观察性 :虽然没有严格定义,但可观察性是一个通用术语,用于描述与提高系统意识和可视性有关的过程和技术。 这可以包括监视,指标,可视化,跟踪和日志分析。
  • 资源 :在监视和软件系统的情况下,资源是任何可用或有限的依赖。 根据正在讨论的系统的一部分,所认为的资源可能会有很大的不同。
  • 延迟 :延迟是衡量完成某个动作所需的时间。 取决于组件,这可以是处理,响应或旅行时间的度量。
  • 吞吐量 :吞吐量表示系统可以处理的最大处理或遍历速率。 这可能取决于软件或硬件设计。 通常理论吞吐量和实际观测吞吐量之间存在重要区别。
  • 性能 :性能是衡量系统完成工作效率的一般指标。 性能是一个总括性的术语,通常包含吞吐量,延迟或资源消耗等工作因素。
  • 饱和度 :饱和度是正在使用的容量的量度。 完全饱和表示目前正在使用100%的容量。
  • 可视化 :可视化是以一种格式呈现指标数据的过程,允许通过图表或图表进行快速,直观的解释。
  • 日志聚合 :日志聚合是对日志文件进行编译,组织和编制索引的操作,以便于管理,搜索和分析。 虽然与监测分开,但可将聚合日志与监测系统结合使用,以确定原因并调查故障。
  • 数据点 :数据点是单个度量的单一度量。
  • 数据集 :数据集是指标数据点的集合。
  • 单位 :单位是测量值的上下文。 一个单位定义测量的大小,范围或数量,以便了解程度并进行比较。
  • 百分比单位 :百分比单位是作为有限整体的一部分的度量。 百分比单位表示总价值中有多少价值。
  • 费率单位 :费率单位表示在一段时间内度量的大小。
  • 时间序列 :时间序列数据是一系列代表随时间变化的数据点。 大多数度量标准最好用时间序列表示,因为单个数据点通常在特定时间表示一个值,并且所得到的一系列点用于显示随时间的变化。
  • 采样率 :采样率是一个代表连续采集代表数据点的频率的度量。 更高的采样率更准确地表示测量的行为,但需要更多的资源来处理额外的数据点。
  • 分辨率 :分辨率是指组成数据集的数据点的密度。 具有较高分辨率的集合在同一时间帧内表示较高的采样率和相同行为的更细粒度的视图。
  • 仪表 :仪表是跟踪软件的行为和性能的能力。 这是通过向软件添加代码和配置来输出可以被监控系统消耗的数据来实现的。
  • 观察者效应 :观察者效应是监测系统本身对所观察现象的影响。 由于监督占用资源,衡量行为和绩效的行为将改变所产生的价值。 监控系统力求避免增加不必要的开销,以尽量减少这种影响
  • 过度监控 :当配置的度量和警报的数量与其有用性成反比时,发生过度监控。 过度监测可能会给基础设施带来压力,难以找到相关数据,导致团队失去对监测和警报系统的信任。
  • 警报疲劳 :警报疲劳是由频繁,不可靠或不恰当的优先警报引起的人为反应敏感。 警报疲劳可能会导致操作员忽视严重的问题,通常表示警报状况需要重新评估。
  • 阈值 :警报时,阈值是可接受值和不可接受值之间的边界,如果超过,则会触发警报。 通常情况下,警报被配置为在值超过阈值一段时间时触发,以避免发送临时尖峰警报。
  • 分位数 :分位数是用来根据数据值将数据集分成不同的组的一个分隔点。 分位数被用于将数值放入代表数据总体部分的“桶”中。 通常,这被用来区分常见值和异常值,以更好地理解代表性和极端情况的构成。
  • 趋势 :趋势是一组数值所表示的大方向。 在确定被跟踪组件的一般状态时,趋势比单一值更可靠。
  • 白盒监控 :白盒监控是用来描述依赖于被测组件内部状态的监控的术语。 白盒监控可以提供对系统状态的详细了解,有助于识别问题的原因。
  • 黑盒监控 :黑盒监控是通过仅查看其输入,输出和行为来观察系统或组件的外部状态的监控。 这种类型的监控可以与用户的系统体验紧密结合,但对于发现问题的原因则不太有用。

结论

收集指标,监控组件和配置警报是设置和管理生产基础架构的重要组成部分。 能够说出系统中发生的事情,哪些资源需要关注,什么导致放缓或中断,是非常宝贵的。 虽然设计和实施您的监控设置可能是一个挑战,但这是一项投资,可以帮助您的团队优先考虑其工作,将监督责任委派给自动化系统,并了解基础架构和软件对稳定性和性能的影响。


分享按钮