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