基础设施与应用监控之监控与报警实践

电玩女神 2022-05-10 07:56 317阅读 0赞

# 介绍 #

监控系统有助于提高基础架构和应用程序的可视性，并定义可接受的性能和可靠性范围。通过了解要测量的组件以及针对不同方案关注的最合适的指标，您可以开始规划涵盖服务的所有关键部分的监控策略。在我们关于从您的[基础架构和应用程序收集指标][Link 1]的指南中，我们引入了一个流行的框架来识别高价值指标，然后将部署分层，以讨论在不同阶段收集的内容。

在本文中，我们将讨论构成监控系统的组件以及如何使用它们来实施监控策略。我们将首先回顾有效的，可靠的监测系统的基本职责。之后，我们将介绍监控系统的各个元素如何满足这些功能要求。然后，我们将讨论如何最好地将您的监控策略转换为仪表板和警报策略，为您的团队提供所需的信息，而无需在无效的时间中引起他们的注意力。

审查度量，监视和警报系统的重要性质

在我们介绍[指标，监控和警报指南][Link 2]的最后一节中，我们讨论了有效监控系统的一些最重要的特性。由于我们将关注这些系统的核心组件，因此查看我们认为有用或必要的特征非常有用：

*  **独立于大多数其他基础架构**：为了准确收集数据并避免对性能产生负面影响，大多数监控组件应使用与其他应用程序分开的专用资源。
 *  **可靠和值得信赖**：由于监控用于评估其他系统的运行状况，因此确保监控系统本身正确且可用是非常重要的。
 *  **易于使用的摘要和详细信息视图**：如果数据不易理解或无法操作，则数据无用。允许操作员查看摘要视图，然后在重要区域发现更多详细信息，这在调查期间非常有价值。
 *  **维护历史数据的有效策略**：了解典型模式是什么以识别异常非常重要。在较长的时间线上，这可能需要访问系统必须能够检索和访问旧的数据。
 *  **能够关联来自不同来源的因素**：以有组织的方式显示部署中不同部分的信息对于识别模式和相关因素非常重要。
 *  **易于开始跟踪新指标或基础架构**：您的监控系统必须随着应用程序和基础架构的变化而发展。过时或不完整的监控范围会降低对工具和数据的信任。
 *  **灵活且强大的警报**：警报功能必须能够根据您定义的条件在各种渠道和优先级中发送通知。

考虑到这些属性，让我们来看看构成监控系统的内容。

# 监控系统的各个部分 #

监控系统由几个不同的组件和接口组成，它们共同协作以收集，可视化和报告部署的运行状况。我们将介绍以下基本的个别部分。

## 分布式监视代理和数据导出程序 ##

虽然可以将大部分监控系统部署到专用服务器或服务器，但需要从整个基础架构中的许多不同来源收集数据。为此，监控代理（一种旨在收集数据并将数据转发到集合端点的小型应用程序）安装在整个网络中的每台机器上。这些代理从安装它们的主机收集统计信息和使用度量标准，并将它们发送到中央监视软件。

代理程序在整个系统中的每个主机上作为永远在线守护程序运行。它们可能包括一个基本配置，用于与远程数据端点安全地进行身份验证，定义数据频率或采样策略，以及为主机数据设置唯一标识符。为了减少对其他服务的影响，代理必须使用最少的资源，并且能够在几乎没有管理的情况下运行。理想情况下，在新节点上安装代理并开始向中央监控系统发送指标应该是微不足道的。

监视代理程序通常会收集通用的主机级别度量标准，但也可以使用代理来监视Web或数据库服务器等软件。但是，对于大多数特殊类型的软件，必须通过修改软件本身来收集和导出数据，或者通过创建解析软件状态端点或日志条目的服务来构建自己的代理。许多流行的监控解决方案都有可用的库，可以更轻松地为您的服务添加自定义检测。与代理软件一样，必须注意确保您的自定义解决方案最小化其占用空间，以避免影响应用程序的运行状况或性能。

到目前为止，我们已经对基于推送的监控架构做了一些假设，其中代理将数据推送到中心位置。但是，也可以使用基于拉的设计。在基于拉的监视系统中，各个主机负责在可访问的端点处以已知格式收集，聚合和提供度量。监视服务器轮询每个主机上的度量标准端点以收集度量指标数据。通过端点收集和呈现数据的软件具有许多与代理相同的要求，但通常需要较少的配置，因为它不需要知道如何访问其他计算机。

## 度量指标入口 ##

在任何监控系统中最繁忙的部分之一就是度量指标入口组件。由于数据不断生成，因此收集过程需要足够强大以处理大量活动，并与存储层协调以正确记录传入数据。

对于基于推送的系统，度量指标入口端点是网络上的中心位置，其中每个监视代理程序或统计信息聚合器发送其收集的数据。端点应该能够同时验证和接收来自大量主机的数据。度量系统的入口端点通常负载平衡或大规模分布，以提高可靠性并跟上大量流量。

对于基于拉的系统，相应的组件是轮询机制，它探测并解析在各个主机上公开的度量标准端点。这有一些相同的要求，但有些责任是相反的。例如，如果单个主机需要实现身份验证，则度量收集过程必须能够提供正确的凭据以登录和访问安全端点。

## 数据管理层 ##

数据管理层负责组织和记录来自度量指标入口组件的传入数据，并响应来自管理层的查询和数据请求。度量数据通常以称为时间序列的格式记录，该时间序列表示值随时间的变化。时间序列数据库（专门用于存储和查询此类数据的数据库）经常在监视系统中使用。

数据管理层的主要职责是存储从主机接收或收集的传入数据。存储层至少应记录报告的度量标准，观察到的值，生成值的时间以及生成它的主机。

对于较长时间的持久性，当集合超出处理、 内存或存储的本地限制时，存储层需要提供导出数据的方法。因此，存储层还需要能够批量导入数据，以便在必要时将历史数据重新提取到系统中。

数据管理层还需要提供对存储信息的有组织的访问。对于使用时间序列数据库的系统，此功能由内置查询语言或API提供。这些可用于交互式查询和数据探索，但主要消费者可能是数据显示仪表板和警报系统。

## 可视化和仪表板层 ##

建立在数据管理层之上的是与之交互的接口，以便了解正在收集的数据。由于指标是时间序列数据，因此数据最好表示为x轴上的时间图。这样，您就可以轻松了解值随时间的变化情况。可以在不同的时间尺度上显示度量标准，以了解长时间内的趋势以及可能当前影响您的系统的最新更改。

可视化和数据管理层都涉及确保来自各种主机或应用程序堆栈的不同部分的数据可以整体覆盖和查看。幸运的是，时间序列数据提供了一致的比例，有助于识别同时发生的事件或变化，即使影响分布在不同类型的基础架构中也是如此。能够选择以交互方式覆盖的数据允许操作员构建对手头任务最有用的可视化。

常用的图表和数据通常被组织到已保存的仪表板中。这些在许多情况下都很有用，可以作为永远在线显示器的当前健康指标的连续表示，也可以作为故障排除或深入潜入系统特定区域的重点门户。例如，在容量规划时，具有整个系统中物理存储容量详细分类的仪表板可能很重要，但可能不需要参考日常管理。轻松构建通用和聚焦仪表板有助于使您的数据更易于访问和操作。

## 警报和阈值功能 ##

虽然图形和仪表板是您理解系统中数据的首选工具，但它们仅在人工操作员查看页面的环境中有用。监控系统最重要的职责之一是减轻团队成员整天监视您的系统，以便他们可以开展更有价值的活动。为了使这一点可行，系统必须能够在必要时引起您的注意，以便可以使您意识到重要的变化。监控系统使用用户定义的度量标准阈值和警报系统来完成此任务。

警报系统的目标是在数据发生重要变化时可靠地通知操作员，否则将其留下。由于这需要系统知道您认为重要事件的内容，因此您必须定义警报标准。警报定义由通知方法和度量阈值组成，系统根据传入数据持续评估。阈值通常定义指定时间范围内度量标准的最大或最小平均值，而通知方法描述如何发送警报。

警报中最困难的部分之一是找到一个平衡点，使您能够在不过度警报的情况下对问题做出响应。要实现这一点，您需要了解哪些指标是实际问题的最佳指标，哪些问题需要立即关注，以及哪种通知方法最适合不同的方案。为了支持这一点，阈值定义语言必须足够强大，以充分描述您的标准。同样，通知组件必须提供适合各种严重程度的通信方法。

# 黑盒和白盒监控 #

现在我们已经描述了监控系统的各个部分如何有助于提高部署的可见性，我们可以讨论一些可以定义阈值和警报的方法，以便为您的团队提供最佳服务。我们首先讨论黑盒和白盒监控之间的区别。

黑盒和白盒监控描述了不同的监控模型。它们不是相互排斥的，因此系统通常使用各种类型的混合物来利用它们的独特优势。

黑盒监控仅根据外部可见因素描述警报定义或图表。这种监控方式采用外部视角来保持对应用程序或服务的公共行为的关注。由于不了解底层组件的运行状况，黑盒监控从用户的角度为您提供有关系统功能的数据。虽然此视图可能看起来有限制，但此信息会严格映射到主动影响客户的问题，因此它们是警报触发器的良好候选者。

白盒监控描述了基于有关基础架构的内部信息的任何监控。由于内部流程的数量远远超过了外部可见行为，因此您可能会有更高比例的白盒数据。由于它可以提供有关您系统的更全面的信息，因此白盒监控有机会提供预测。例如，通过跟踪资源使用的变化，它可以在您需要扩展某些服务以满足新需求时通知您。

黑盒子和白盒子只是将不同类型的视角分类到系统中的方法。可以访问系统内部可见的白盒数据，有助于调查问题，评估根本原因，以及在出现问题或正常管理时查找相关因素。另一方面，黑盒监控可以通过立即显示用户影响来帮助快速检测严重问题。

# 通过警报类型来匹配问题严重性 #

警报和通知是您的监控系统中最重要的部分。如果没有关于重要更改的通知，您的团队将不会意识到影响您系统的事件，或者需要主动监控您的仪表板才能及时了解情况。另一方面，过度激进的消息传递与高百分比的误报，非紧急事件或模糊的消息传递可能弊大于利。

在本节中，我们将讨论不同级别的通知以及如何最好地使用每个通知以最大化其有效性。之后，我们将讨论选择警报的内容以及通知应该完成的一些标准。

## 报警 ##

从最高优先级警报类型开始，报警是由紧急情况引起对系统的关键问题的注意的通知。此类警报应用于因严重性要求立即解决的情况。寻呼系统需要一种可靠，积极的方式来通知有责任和有权解决问题的人。

报警应保留用于系统的关键问题。由于它们代表的问题类型，它们是系统发送的最重要的警报。良好的寻呼系统可靠、持久且具有足够的侵略性，以至于无法合理地忽略它们。为确保响应，寻呼系统通常包括一个选项，用于在一定时间内未确认而通知辅助人员或其他工作组。

因为报警本质上具有令人难以置信的破坏性，所以应该谨慎使用它们：只有在明确存在操作上不可接受的问题时才使用它们。通常，这意味着使用黑盒技术与系统中观察到的症状相关联。虽然可能很难确定后端Web主机最大化连接的影响，但是比您的域无法访问的重要性要小得多。

## 次要通知 ##

低级别严重性是电子邮件通知。这些旨在留下持续的提醒，即操作员在处于有利位置时应调查发生的情况。与报警不同，通知式警报表示并不需要立即采取行动，因此通常由工作人员处理，而不是警告随叫随到的员工。如果您的企业没有管理员实时工作，则通知应有可能等到下一个工作日时处理。

监控帮助团队生成的电子邮件了解他们下次活动时应该关注的工作。由于通知不应用于当前影响生产的关键问题，因此它们通常基于白盒指标，可以预测或识别需要尽快解决的不断变化的问题。

其他时候，通知警报设置为监视与寻呼警报相同的行为，但设置为较低的，不太重要的阈值。例如，您可以在应用程序在一段时间内显示延迟略有增加时定义通知警报，并在延迟增加到不合理的数量时发送相应的报警。

通常，通知最适合需要响应的情况，但不会对系统的稳定性构成直接威胁。在这些情况下，您希望提高对问题的认识，以便您的团队可以在影响用户或转换为更大的问题之前进行调查和缓解。

## 记录信息 ##

虽然技术上不是警报，但有时您可能希望在以后可以轻松访问的位置记录特定的观察行为，而不会立即引起任何人的注意。在这些情况下，设置仅记录信息的阈值可能很有用。这些可以写入文件或用于增加监视系统中仪表板上的计数器。目标是为调查提供易于编译的信息，以减少操作员必须构建的查询数量以收集信息。

此策略仅适用于优先级非常低且无需自行响应的方案。它们最大的效用是关联相关因素并总结时间点数据，以后可以作为补充来源参考。您可能没有这种类型的许多触发器，但是如果您在每次出现问题时发现自己查找相同的数据，它们可能会很有用。提供一些相同好处的替代方案是保存的查询和自定义调查仪表板。

# 何时避免警报 #

重要的是要清楚警告应该向您的团队指出什么。每个警报都应表示发生了需要手动操作人工或输入决策的问题。由于这一重点，当您考虑提醒警报时，请注意可以自动进行反应的任何机会。

在以下情况下可以设计自动修复：

*  可识别的签名可以可靠地识别问题
 *  响应总是一样的
 *  响应不需要任何人为输入或决策

有些响应比其他响应更容易自动化，但通常情况下，符合上述条件的任何方案都可以编写脚本。响应仍然可以与警报阈值相关联，但是触发器可以启动脚本来修复以解决问题，而不是向人员发送消息。每次发生这种情况时都要记录可以提供有关系统运行状况以及度量标准阈值和自动度量的有用信息。

重要的是要记住，自动化流程也会遇到问题。最好为脚本响应添加额外的警报，以便在自动化失败时通知操作员。这样，不干涉的响应将处理大多数情况，同时您的团队将收到需要干预的事件的通知。

# 设计有效阈值和警报 #

现在我们已经介绍了可用的不同警报介质以及适合每种情况的一些场景，我们可以讨论好警报的特征。

## 由具有真实用户影响的事件触发 ##

如前所述，基于具有真实用户影响的方案的警报是最佳的。这意味着分析不同的故障或性能降级情况，并了解它们如何以及何时可以涉及到用户与之交互的层。

这需要充分了解您的基础架构冗余，不同组件的关系以及组织的可用性和性能目标。您的目标是发现可以可靠地指示当前或即将发生的用户影响问题的症状指标。

## 具有渐变严重性的阈值 ##

在确定症状指标后，下一个挑战是确定用作阈值的适当值。您可能必须使用试验和错误来发现某些指标的正确阈值。

如果可用，请检查历史值以确定过去需要修复的方案。对于每个度量标准，最好定义一个“紧急”阈值，该阈值将触发一个报警。同时也定义与较低优先级消息传递相关联的一个或多个阈值。定义新警报后，请询问有关阈值是否过于激进或不够敏感的反馈，以便您可以对系统进行微调，以更好地符合您团队的期望。

## 包含适当的上下文 ##

最大限度地减少响应者开始调查问题所需的时间，可帮助您更快地从事件中恢复。为此，尝试在警报文本中提供上下文非常有用，这样操作员可以快速了解情况并开始处理适当的后续步骤。

警报应清楚地指出受影响的组件和系统，触发的度量标准阈值以及事件开始的时间。警报还应提供可用于获取更多信息的链接。这些链接可能是指向与触发指标关联的特定仪表板的链接，如果生成自动故障单，则链接到监控系统的警报页面，其中提供了更详细的上下文。

目标是为操作员提供足够的信息来指导他们的初始响应，并帮助他们专注于手头的事件。提供有关事件的每条信息既不是必需的，也不是推荐的，但提供基本的详细信息以及下一步的选项可以缩短响应的初始发现阶段。

## 发送给合适的人 ##

如果警报不可操作，则警报无效。通常，警报是否可操作取决于响应人员的知识水平，经验和许可。对于特定规模的组织，在某些情况下，确定适当的人员或群组信息是直截了当的，而在其他情况下则是模棱两可的。为不同的团队开展随叫随到的轮换并设计具体的升级计划可以消除这些决策中的一些模糊性。

随叫随到的轮换应包括足够的能力，以避免倦怠和警觉疲劳。最好是您的警报系统包括一个用于安排随叫随到的班次的机制，但如果没有，您可以根据您的日程安排制定手动旋转警报联系人的程序。您可能有多个由系统特定部分的所有者组成的待命轮换。

升级计划是确保事件发生在正确人员身上的第二个工具。如果您的员工每天24小时都会覆盖您的系统，最好将监控系统生成的警报发送给在职员工而不是随叫随到的轮换。然后响应者可以自己执行处理，或者如果他们需要额外的帮助或专业知识，则可以决定手动寻呼呼叫操作员。制定计划何时以及如何升级问题可以最大限度地减少不必要的警报并保持报警所代表的紧迫感。

# 结论 #

在本文中，我们讨论了监控和警报如何在实际系统中工作。我们首先了解监控系统的不同部分如何工作以满足组织对意识和响应能力的需求。我们讨论了黑盒和白盒监控之间的区别，作为思考不同警报线索的框架。之后，我们讨论了不同类型的警报以及如何最好地将事件严重性与适当的警报媒体相匹配。最后，我们介绍了有效警报流程的特点，以帮助您设计一个可提高团队响应能力的系统。

[Link 1]: https://blog.csdn.net/peterwanghao/article/details/82837368
[Link 2]: https://blog.csdn.net/peterwanghao/article/details/82784963