介绍
监控系统有助于提高对基础架构和应用程序的可见性，并定义可接受的性能和可靠性范围。 通过了解要衡量的组件以及针对不同场景要关注的最合适的指标，您可以开始规划涵盖服务所有关键部分的监控策略。 在我们关于 从您的基础设施和应用程序中收集指标 的指南中，我们介绍了一个流行的框架来识别高价值指标，然后将部署分解成层来讨论在各个阶段收集的内容。
在本指南中，我们将讨论构成监控系统的组件以及如何使用它们来实施您的监控策略。 我们将首先回顾一个有效、可靠的监测系统的基本职责。 之后，我们将介绍监控系统的元素如何满足这些功能要求。 然后，我们将讨论如何最好地将您的监控策略转换为仪表板和警报策略，从而为您的团队提供他们需要的信息，而无需在不必要的时间请求他们的关注。
审查指标、监控和警报系统的重要质量
在我们的 指标、监控和警报简介 指南的最后一节中，我们讨论了 有效监控系统 的一些最重要的品质。 由于我们将暂时查看这些系统的核心组件，因此查看我们认为有用或必要的特征很有用：
- 独立于大多数其他基础设施：为了准确收集数据并避免对性能产生负面影响，大多数监控组件应使用与其他应用程序分开的专用资源。
- 可靠且值得信赖：由于监控用于评估其他系统的健康状况，因此确保监控系统本身正确且可用非常重要。
- 易于使用的摘要和详细视图：如果数据不可理解或不可操作，则数据没有用处。 允许操作员查看摘要视图，然后在重要区域中发现更多细节，这在调查期间非常有价值。
- 维护历史数据的有效策略：了解典型模式的特征对于识别异常非常重要。 在更长的时间内，这可能需要访问您的系统必须能够检索和访问的旧数据。
- 能够关联来自不同来源的因素：以有组织的方式显示来自部署不同部分的信息对于识别模式和相关因素非常重要。
- 易于开始跟踪新指标或基础设施：您的监控系统必须随着您的应用程序和基础设施的变化而发展。 过时或不完整的监控覆盖会降低您对工具和数据的信任。
- 灵活而强大的警报：警报功能必须能够根据您定义的条件以各种渠道和优先级发送通知。
考虑到这些属性，让我们看一下构成监控系统的要素。
监控系统的组成部分
监控系统由几个不同的组件和接口组成，它们共同工作以收集、可视化和报告部署的健康状况。 我们将在下面介绍基本的各个部分。
分布式监控代理和数据导出器
虽然大部分监控系统可能部署到一个或多个专用服务器，但需要从整个基础架构中的许多不同来源收集数据。 为此，在整个网络中的每台机器上都安装了一个监控代理（一种旨在收集数据并将数据转发到收集端点的小型应用程序）。 这些代理从安装它们的主机收集统计数据和使用指标，并将它们发送到中央监控软件。
代理在整个系统的每台主机上作为永远在线的守护程序运行。 它们可能包括一个基本配置，用于与远程数据端点进行安全身份验证，定义数据频率或采样策略，并为主机数据设置唯一标识符。 为了减少对其他服务的影响，代理必须使用最少的资源，并且能够在几乎没有管理的情况下进行操作。 理想情况下，在新节点上安装代理并开始向中央监控系统发送指标应该是微不足道的。
监控代理通常会收集通用的主机级指标，但也可以使用用于监控 Web 或数据库服务器等软件的代理。 然而，对于大多数专业类型的软件，必须通过修改软件本身或通过创建解析软件状态端点或日志条目的服务来构建自己的代理来收集和导出数据。 许多流行的监控解决方案都有可用的库，可以更轻松地将自定义检测添加到您的服务中。 与代理软件一样，必须注意确保您的自定义解决方案最大限度地减少其占用空间，以避免影响应用程序的运行状况或性能。
到目前为止，我们已经对基于推送的监控架构做出了一些假设，其中代理将数据推送到中心位置。 但是，也可以使用基于拉动的设计。 在基于拉取的监控系统中，各个主机负责在可访问的端点以已知格式收集、聚合和提供指标。 监控服务器轮询每个主机上的指标端点以收集指标数据。 通过端点收集和呈现数据的软件与代理有许多相同的要求，但通常需要较少的配置，因为它不需要知道如何访问其他机器。
指标入口
在任何给定时间，监控系统最繁忙的部分之一是指标入口组件。 由于数据不断生成，因此收集过程需要足够强大以处理大量活动并与存储层协调以正确记录传入数据。
对于基于推送的系统，指标入口端点是网络上的一个中心位置，每个监控代理或统计聚合器都将其收集的数据发送到该位置。 端点应该能够同时验证和接收来自大量主机的数据。 度量系统的入口端点通常是负载平衡或大规模分布的，以确保可靠性和跟上大量流量。
对于基于拉取的系统，相应的组件是轮询机制，它伸出并解析暴露在各个主机上的指标端点。 这有一些相同的要求，但有些职责是相反的。 例如，如果单个主机实施身份验证，则指标收集过程必须能够提供正确的凭据以登录和访问安全端点。
数据管理层
数据管理层负责组织和记录来自度量入口组件的传入数据，并响应来自管理层的查询和数据请求。 度量数据通常以称为 时间序列 的格式记录，它表示值随时间的变化。 时间序列数据库（专门用于存储和查询此类数据的数据库）在监控系统中经常使用。
数据管理层的主要职责是存储从主机接收或收集的传入数据。 存储层至少应记录报告的指标、观察到的值、生成值的时间以及生成它的主机。
为了更长时间的持久性，存储层需要提供一种在集合超出处理、内存或存储的本地限制时导出数据的方法。 因此，存储层还需要能够批量导入数据，以便在必要时将历史数据重新摄取到系统中。
数据管理层还需要提供对存储信息的有组织的访问。 对于使用时间序列数据库的系统，此功能由内置查询语言或 API 提供。 这些可用于交互式查询和数据探索，但主要消费者可能是数据演示仪表板和警报系统。
可视化和仪表板层
建立在数据管理层之上的是您与之交互以了解正在收集的数据的接口。 由于指标是时间序列数据，因此数据最好表示为 x 轴上的时间图。 这样，您可以轻松了解值如何随时间变化。 指标可以在不同的时间范围内可视化，以了解长期趋势以及当前可能影响您的系统的最新变化。
可视化层和数据管理层都涉及确保来自不同主机或应用程序堆栈不同部分的数据可以被覆盖和整体查看。 幸运的是，时间序列数据提供了一致的规模，有助于识别同时发生的事件或变化，即使影响分布在不同类型的基础设施中。 能够以交互方式选择要覆盖的数据允许操作员构建对手头任务最有用的可视化。
常用的图表和数据通常被组织到保存的仪表板中。 这些在许多情况下都很有用，既可以作为持续显示的当前健康指标的持续表示，也可以作为用于故障排除或深入了解系统特定区域的集中门户。 例如，在进行容量规划时，具有整个车队的物理存储容量详细细分的仪表板可能很重要，但可能不需要在日常管理中参考。 轻松构建通用和集中的仪表板有助于使您的数据更易于访问和操作。
警报和阈值功能
虽然图表和仪表板将是您了解系统中数据的首选工具，但它们仅在人工操作员查看页面的情况下才有用。 监控系统最重要的职责之一是让团队成员免于积极监视您的系统，以便他们可以从事更有价值的活动。 为了使这一点可行，系统必须能够在必要时引起您的注意，这样您就可以确信自己会意识到重要的变化。 监控系统使用用户定义的度量阈值和警报系统来实现这一点。
警报系统的目标是在数据表明发生重要变化时可靠地通知操作员，否则不要管他们。 由于这要求系统知道您认为什么是重大事件，因此您必须定义警报标准。 警报定义由系统根据传入数据持续评估的通知方法和度量阈值组成。 阈值通常定义指标在指定时间范围内的最大或最小平均值，而通知方法描述如何发出警报。
警报最困难的部分之一是找到一种平衡，使您能够在不过度警报的情况下对问题做出响应。 要做到这一点，您需要了解哪些指标是实际问题的最佳指示，哪些问题需要立即关注，以及哪些通知方法最适合不同的场景。 为了支持这一点，阈值定义语言必须足够强大以充分描述您的标准。 同样，通知组件必须提供适合各种严重程度的通信方法。
黑盒和白盒监控
既然我们已经描述了监控系统的各个部分如何有助于提高对您的部署的可见性，我们可以讨论一些您可以定义阈值和警报以最好地为您的团队服务的方法。 我们将首先讨论黑盒和白盒监控之间的区别。
黑盒和白盒监控描述了不同的监控模型。 它们不是相互排斥的，因此系统经常混合使用每种类型来利用它们的独特优势。
黑盒监控 描述仅基于外部可见因素的警报定义或图形。 这种监控风格采用外部视角来保持对应用程序或服务的公共行为的关注。 由于对底层组件的健康状况没有特殊了解，黑盒监控可以从用户的角度为您提供有关系统功能的数据。 虽然此视图可能看起来具有限制性，但此信息与正在积极影响客户的问题密切相关，因此它们是警报触发器的良好候选者。
替代方案 白盒监控 也非常有用。 白盒监控描述了基于有关您的基础设施的特权内部信息的任何监控。 由于内部流程的数量大大超过了外部可见的行为，因此您可能会拥有更高比例的白盒数据。 由于它使用有关您的系统的更全面的信息进行操作，因此白盒监控有机会进行预测。 例如，通过跟踪资源使用的变化，它可以在您可能需要扩展某些服务以满足新需求时通知您。
黑盒和白盒只是将不同类型的观点分类到系统中的方法。 访问系统内部可见的白盒数据有助于调查问题、评估根本原因以及在已知问题或用于正常管理目的时找到相关因素。 另一方面，黑盒监控通过立即展示用户影响来帮助快速检测严重问题。
将严重性与警报类型匹配
警报和通知是监控系统中最重要的部分。 如果没有关于重要更改的通知，您的团队将不会意识到影响您系统的事件，或者需要主动监控您的仪表板以随时了解情况。 另一方面，带有高比例误报、非紧急事件或模棱两可的消息的过于激进的消息可能弊大于利。
在本节中，我们将讨论不同级别的通知以及如何最好地使用每个通知以最大限度地提高其有效性。 之后，我们将讨论一些标准来选择提醒什么以及通知应该完成什么。
页面
从最高优先级的警报类型开始，pages 是试图紧急引起人们注意系统关键问题的通知。 此类警报应用于由于其严重性而需要立即解决的情况。 寻呼系统需要一种可靠、积极的方式来联系有责任和权力解决问题的人。
应为系统的关键问题保留页面。 由于它们代表的问题类型，它们是您的系统发送的最重要的警报。 好的分页系统是可靠的、持久的和足够积极的，以至于它们不能被合理地忽略。 为了确保响应，寻呼系统通常包括一个选项，如果第一页在一定时间内没有被确认，则通知第二个人或组。
因为页面本质上具有令人难以置信的破坏性，所以应该谨慎使用它们：只有当很明显存在操作上不可接受的问题时。 通常，这意味着页面使用黑盒技术与系统中观察到的症状相关联。 虽然可能很难确定后端 Web 主机最大化连接的影响，但您的域无法访问的意义要明确得多，并且可能需要一个页面。
次要通知
降低严重性的是通知，如电子邮件和票证。 这些旨在留下一个持久的提醒，即运营商应该在他们处于有利位置时调查发展中的情况。 与页面不同，通知式警报并不意味着需要立即采取行动，因此它们通常由工作人员处理，而不是提醒待命员工。 如果您的企业没有管理员一直在工作，则通知应与可以等到下一个工作日的情况保持一致。
监控生成的工单和电子邮件有助于团队了解他们下一次活跃时应该关注的工作。 由于通知不应用于当前影响生产的关键问题，因此它们通常基于可以预测或识别需要尽快解决的不断演变的问题的白盒指标。
其他时候，通知警报设置为监视与寻呼警报相同的行为，但设置为较低、不太重要的阈值。 例如，当您的应用程序在一段时间内显示延迟小幅增加时，您可以定义通知警报，并在延迟增长到不合理的数量时发送相应的页面。
通常，通知最适合需要响应但不会对系统稳定性构成直接威胁的情况。 在这些情况下，您希望提高对问题的认识，以便您的团队可以在 影响用户或转变为更大的问题之前调查和缓解 。
记录信息
虽然从技术上讲不是警报，但有时您可能希望在以后可以轻松访问的地方记录特定观察到的行为，而无需立即引起任何人的注意。 在这些情况下，设置仅 log 信息的阈值可能很有用。 这些可以写入文件或用于增加监控系统中仪表板上的计数器。 目标是为调查目的提供易于编译的信息，以减少操作员为收集信息而必须构建的查询数量。
此策略仅适用于优先级非常低且无需自行响应的场景。 它们最大的用途是关联相关因素并汇总可在以后作为补充来源引用的时间点数据。 您可能不会有很多此类触发器，但在您发现每次出现问题时都在查找相同数据的情况下，它们可能很有用。 提供一些相同好处的替代方案是保存查询和自定义调查仪表板。
何时避免警报
重要的是要清楚哪些警报应该向您的团队指示。 每个警报都应表明正在发生需要人工操作或输入决策的问题。 由于这种关注，当您考虑要提醒的指标时，请注意任何可以自动化反应的机会。
在以下情况下可以设计自动修复：
- 可识别的签名可以可靠地识别问题
- 响应将始终相同
- 响应不需要任何人工输入或决策
一些响应比其他响应更容易自动化，但通常，任何符合上述标准的场景都可以被脚本化掉。 响应仍然可以与警报阈值相关联，但触发器可以启动脚本补救来解决问题，而不是向人发送消息。 每次发生这种情况时进行记录可以提供有关您的系统运行状况以及指标阈值和自动化措施的有效性的宝贵信息。
重要的是要记住，自动化流程也会遇到问题。 向您的脚本响应添加额外警报是一个好主意，以便在自动化失败时通知操作员。 这样一来，大多数情况下，不干涉的响应将处理，并且您的团队将收到需要干预的事件的通知。
设计有效的阈值和警报
既然我们已经介绍了可用的不同警报媒介以及适用于每种媒介的一些场景，那么我们可以讨论良好警报的特征。
由具有真实用户影响的事件触发
如前所述，基于具有真实用户影响的场景的警报是最好的。 这意味着分析不同的故障或性能下降场景，并了解它们如何以及何时会冒泡到用户与之交互的层。
这需要充分了解您的基础架构冗余、不同组件之间的关系以及您组织的可用性和性能目标。 您的目标是发现能够可靠地指示当前或即将发生的影响用户的问题的症状指标。
具有分级严重性的阈值
确定症状指标后，下一个挑战是确定用作阈值的适当值。 您可能必须通过反复试验来发现某些指标的正确阈值。
如果可用，请检查历史值以确定过去需要补救的情况。 对于每个指标，最好定义一个触发页面的“紧急”阈值和一个或多个与较低优先级消息相关联的“金丝雀”阈值。 定义新警报后，询问阈值是否过于激进或不够敏感，以便您可以微调系统以最好地符合团队的期望。
包含适当的上下文
最大限度地缩短响应者开始调查问题所需的时间有助于您更快地从事件中恢复。 为此，尝试在警报文本中提供上下文很有用，这样操作员可以快速了解情况并开始执行适当的后续步骤。
警报应清楚地指出受影响的组件和系统、触发的度量阈值以及事件开始的时间。 警报还应提供可用于获取更多信息的链接。 这些可能是指向与触发指标相关的特定仪表板的链接、指向您的票务系统的链接（如果生成了自动票证）或指向您的监控系统警报页面的链接，其中提供了更详细的上下文。
目标是为操作员提供足够的信息来指导他们的初步响应并帮助他们专注于手头的事件。 提供您所拥有的有关该事件的每条信息既不是必需的，也不是推荐的，但提供基本细节以及下一步去哪里的一些选项可以缩短您响应的初始发现阶段。
发送给正确的人
如果警报不可操作，则警报没有用处。 通常，警报是否可行取决于响应者的知识水平、经验和权限。 对于具有一定规模的组织，在某些情况下确定合适的人或组来发送消息很简单，而在其他情况下则模棱两可。 为不同的团队制定轮岗轮换并设计具体的升级计划可以消除这些决策中的一些歧义。
待命轮换应包括足够的有能力的人员，以避免倦怠和警觉疲劳。 最好是您的警报系统包含用于安排值班轮班的机制，但如果没有，您可以开发程序以根据您的日程安排手动轮换警报联系人。 您可能有多个由系统特定部分的所有者组成的 on-call 轮换。
升级计划是确保事件传到正确人员的第二个工具。 如果您有员工每天 24 小时覆盖您的系统，最好将监控系统生成的警报发送给值班员工，而不是轮班值班员工。 然后，响应者可以自己执行缓解措施，或者如果他们需要额外的帮助或专业知识，可以决定手动寻呼待命操作员。 制定一个概述问题何时以及如何升级的计划可以最大程度地减少不必要的警报，并保持页面应代表的紧迫感。
结论
在本指南中，我们讨论了监控和警报在实际系统中的工作方式。 我们首先研究了监控系统的不同部分如何工作以满足组织对意识和响应能力的需求。 我们讨论了黑盒和白盒监控之间的区别，作为思考不同警报线索的框架。 之后，我们讨论了不同类型的警报，以及如何最好地将事件严重性与适当的警报媒介相匹配。 最后，我们介绍了有效警报过程的特征，以帮助您设计一个提高团队响应能力的系统。
