介绍
监控系统有助于提高您的基础设施和应用程序的可见性,并定义可接受的性能和可靠性范围。通过了解要测量哪些组件和最适合于不同场景的指标,您可以开始规划一个监控策略,涵盖您的服务的所有关键部分。
在本指南中,我们将讨论构成监控系统的组成部分,以及如何使用它们来实施监控策略,我们将首先审查有效可靠监控系统的基本责任,然后我们将讨论监控系统的组成部分如何满足这些功能要求,然后我们将讨论如何最好地将监控策略转化为仪表板和警报策略,以便为您的团队提供所需的信息,而无需在不合理的时间请求他们的注意。
测量、监测和警报系统的重要品质的审查
在我们的指南(https://andsky.com/tech/tutorials/an-introduction-to-metrics-monitoring-and-alerting)的最后一部分中,我们讨论了一些(有效监控系统的最重要的品质)(https://andsky.com/tech/tutorials/an-introduction-to-metrics-monitoring-and-alerting#important-qualities-of-a-metrics,-monitoring,-and-alerting-system)。
** 独立于大多数其他基础设施**: 为了准确收集数据并避免对业绩产生不利影响,大多数监测部分应使用与其他应用程序分开的专用资源。 () ( )* ** 可靠和可信赖**:由于监测用于评估其他系统的健康,所以必须确保监测系统本身正确和可用。 ( ( )* ** 方便使用摘要和详细意见**: 如果数据不易理解或无法操作,则无用。 允许操作者看到简要观点,然后在重要领域发现更多细节,在调查期间是极其宝贵的。 () ( )* ** 维持历史的有效战略 数据**: 必须了解典型规律是什么样子,才能识别出异常现象. 在更长的时间内,这可能需要访问旧数据,而您的系统必须能够检索和访问这些数据。 () ( )* ** 与来自不同来源的腐蚀因素有关**:以有条不紊的方式显示来自部署的不同部分的信息对于确定模式和关联因素十分重要。 () ( )* ** 容易开始跟踪新计量或基础设施**: 您的监控系统必须随着您的应用和基础设施的变化而发展。 控制或监测覆盖不完整会降低对工具和数据的信任度。 () ( )* ** 灵活而有力的警告**: 提醒功能必须能够根据您定义的条件在各种渠道和优先级发送通知。 (_) (英语)
考虑到这些属性,让我们看看什么构成监控系统。
监控系统的部分
监控系统由几个不同的组件和接口组成,它们一起收集、可视化和报告您的部署的健康状况。
分布式监控代理商和数据出口商
虽然大部分监控系统可能部署到专用服务器或服务器,但数据需要从整个基础设施的许多不同的来源收集。 为了做到这一点,一个监控代理 — 一个旨在收集和传输数据到收集终端的小型应用程序 — 安装在整个网络的每个单个机器上。
代理人可以在整个系统上运行为每个主机的永久接入式标识符,它们可能包括一个基本配置,以便与远程数据终端安全地进行身份验证,定义数据频率或采样策略,并为主机的数据设置独特的标识符。
监控代理通常收集通用,主机级指标,但监控软件的代理,如网络或数据库服务器也可用。 对于大多数专门类型的软件,然而,数据必须通过修改软件本身或通过创建自己的代理来收集和出口,通过创建一个服务,分析软件的状态终端点或日志条目。 许多流行的监控解决方案都有库,以便更容易为您的服务添加自定义仪器。
到目前为止,我们已经对一个以推移为基础的监控架构做了一些假设,在那里代理人将数据推到一个中心位置。然而,基于推移的设计也可用。在以推移为基础的监控系统中,个别主机负责在可访问的终端点收集、汇总和提供已知格式的指标。监控服务器对每个主机的指标终端进行调查,以收集指标数据。通过终点收集和呈现数据的软件有很多与代理人相同的要求,但通常需要更少的配置,因为它不需要知道如何访问其他机器。
英格兰Metrics
监控系统在任何时间最繁忙的部分之一是指数输入组件. 由于数据正在不断生成,收集过程需要足够强大来处理大量活动,并与存储层协调以正确记录输入数据。
对于基于推的系统,指数输入终端是网络上的一个中心位置,每个监测代理或统计集合器都会发送其收集的数据。该终端应该能够同时验证和接收大量主机的数据。
对于基于拉动系统的系统,相应的组件是探讨机制,它可以接触和分析个别主机暴露的指标终端点,这有某些相同的要求,但一些责任被扭转。
数据管理层
数据管理层负责组织和记录来自指数输入组件的输入数据,并响应来自管理层的查询和数据请求。 指数数据通常以称为 time series的格式记录,代表了随着时间的推移值的变化。
数据管理层的主要责任是存储所接收的数据或从主机收集的数据. 至少,存储层应该记录所报告的指标、观察到的值、值生成时间和生成它的主机。
为了在较长的时间内保持持久性,存储层需要提供一种方法来导出数据,当收集超过处理、存储或存储的局部限制时。
数据管理层还需要为存储的信息提供有组织的访问。对于使用时间序列数据库的系统,这种功能是由内置的查询语言或API提供的。
可视化和 Dashboard 层
建立在数据管理层的顶部是您互动的界面,以了解所收集的数据。由于指标是时间序列数据,数据最好以x轴上的时间图表来表示。
可视化和数据管理层既有助于确保来自不同主机或应用程序堆栈的不同部分的数据可以被覆盖并全面查看。幸运的是,时间序列数据提供了一致的规模,有助于识别同时发生的事件或变化,即使影响分布在不同类型的基础设施中。
通常使用的图表和数据通常被组织成存储的仪表板,这些仪表板在许多情况下都是有用的,无论是作为常规显示的当前健康指标的连续表示,还是针对系统的特定区域进行故障排除或深度潜水的专注门门门户。例如,在容量规划时,具有详细的物理存储容量分布的仪表板可能很重要,但可能不需要用于日常管理。
警报和门槛功能
虽然图表和仪表板将是您理解系统中的数据的工具,但它们只在人类操作员正在浏览页面的情况下才有用。监控系统最重要的责任之一是免除团队成员积极监控您的系统,以便他们能够进行更有价值的活动。
警报系统的目的是在数据显示重要变化时,可靠地通知操作员,否则将其单独留给操作员。因为这需要系统知道你认为是重大事件,你必须定义你的警报标准。 警报定义由通知方法和指标门槛组成,系统根据输入数据不断评估。
警报的最困难部分之一是找到一个平衡,使您能够对问题做出响应,而不是过度警告。要做到这一点,您需要了解哪些指标是真实问题的最佳指标,哪些问题需要立即关注,以及哪些通知方法最适合不同场景。
黑盒和白盒监控
现在我们已经描述了监控系统的不同部分如何有助于提高部署的可见性,我们可以谈论一些您可以定义门槛和警报的方式,以便更好地为您的团队服务。
黑盒和白盒监控描述了不同的监控模式,它们不是相互排斥的,因此系统经常使用每个类型的混合物来利用它们的独特优势。
黑匣子监控描述了一个仅基于外部可见因素的警报定义或图表。这种监控风格采用外部视角,以保持对应用程序或服务的公共行为的关注。没有对潜在组件的健康状况的特殊知识,黑匣子监控从用户角度为您提供有关系统功能的数据。
另外,白盒监测也非常有用。白盒监测描述了基于关于您的基础设施的特权、内部信息进行的任何监测,因为内部流程的数量远远超过了外部可见的行为,因此您可能拥有更高的白盒数据比例。
黑匣子和白匣子只是将不同类型的视角分类到您的系统中的一种方式,可以访问白盒数据,在那里可以看到您的系统内部数据,这有助于调查问题,评估根源,并在问题已知或用于正常管理目的时找到相关因素。
与警报类型相匹配的严重性
警告和通知是您的监控系统最重要的部分,以获得正确的权利。如果没有有关重要变化的通知,您的团队或不会意识到影响您的系统的事件,或者需要积极监控您的仪表板,以保持信息。
在本节中,我们将讨论不同级别的通知,以及如何最好地使用每个级别以最大限度地提高其有效性。
页面
從最優先的警報類型開始, ** 頁面** 是試圖緊急引起系統關鍵問題的通知。 該警報類別應用於因其嚴重性而需要立即解決的情況。
页面应该被保留在与您的系统相关的关键问题上。 由于它们代表的问题的类型,它们是您系统发送的最重要的警告。 好的页面系统是可靠的,持久的,并且足够有攻击性,以便无法合理地忽视它们。 为了确保响应,页面系统通常包括一个通知第一个页面在一定时间内未被认可的次要人员或组的选项。
由于页面本质上是令人难以置信的破坏性,所以应该谨慎地使用它们:只有当它清楚地表明存在一个操作上不可接受的问题时,这通常意味着页面与您的系统中使用黑匣子技术观察到的症状有关。
二级通知
重度下降是电子邮件和门票等 通知。这些通知旨在留下一个持续的提醒,即运营商应该在他们处于良好的位置时调查发展形势。与页面不同,通知风格的警告不是为了表明需要立即采取行动,因此通常由工作人员处理,而不是提醒呼叫员工。
通过监控生成的门票和电子邮件有助于团队了解他们下次活跃时应该专注于什么工作,因为通知不应该用于当前影响生产的关键问题,因此它们通常基于白盒指标,可以预测或识别需要很快解决的正在演变的问题。
其他情况下,通知警报设置为跟踪与页面警报相同的行为,但设置为较低、较不关键的门槛,例如,当您的应用程序在一段时间内显示延迟小幅增加时,您可能会设置通知警报,并且在延迟增加到不合理时发送相应的页面。
一般来说,在需要响应的情况下,通知是最合适的,但不会对系统的稳定性构成直接威胁. 在这些情况下,您想要提高对一个问题的认识,以便您的团队可以调查并缓解 _before_它影响用户或转化为一个更大的问题。
记录信息
虽然从技术上来说不是一个警告,但有时你可能希望在稍后可以轻松访问的地方注意到特定观察的行为,而不会立即引起任何人的注意。在这些情况下,设置门槛将简单地 log 信息可能是有用的。
这种策略只对具有非常低优先级的场景有意义,不需要自行响应,他们的最大实用工具是对相关因素进行对比,并总结可以后来引用为补充来源的时刻数据。你可能不会有很多这种类型的触发因素,但它们可能在你发现自己每次出现问题时寻找相同的数据的情况下是有用的。
何时避免警报
重要的是要清楚警告应该向您的团队显示什么。每个警告都应该表示正在发生的问题,需要手动的人类行动或对决策的输入。
自动修复可以在以下情况下设计:
- 可识别的签名可以可靠地识别问题
- 答案将始终是相同的
- 答案不需要任何人的投入或决策
一些响应比其他更容易自动化,但一般来说,任何符合上述标准的场景都可以被编写。响应仍然可以绑定到警报门槛,但而不是向某人发送消息,触发器可以启动编写的修复来解决问题。
重要的是要记住,自动化流程也可能出现问题。 将额外的警告添加到您的脚本响应中,以便在自动化失败时通知操作员。
设计有效的门槛和警报
现在,我们已经涵盖了各种可用的警报媒介和一些适合每个情景,我们可以谈论好警报的特征。
由具有实际用户影响的事件引发
如前所述,基于具有实际用户影响的场景的警报是最佳的,这意味着分析不同故障或性能降低的场景,并了解它们如何以及何时会泡沫到用户交互的层面。
这需要对基础设施冗余性、不同组件的关系以及组织的可用性和性能目标有很好的了解,你的目标是发现可以可靠地表明当前或即将到来的用户影响问题的症状指标。
具有毕业严重性的门槛
确定症状指标后,下一个挑战是确定适当的值作为门槛,您可能需要使用试验和错误来发现某些指标的正确门槛。
如果可用,请检查历史值,以确定过去需要修复的场景。对于每个指标,可以定义一个紧急门槛,该门槛会触发页面和与较低优先级消息相关的一个或多个渠道门槛。
提供适当的背景
尽量减少响应者开始调查问题所需的时间有助于您更快地从事件中恢复。
警报应该清楚地表明受影响的组件和系统,触发的指数门槛,以及事件开始的时间。警报还应该提供可以用于获取进一步信息的链接。
提供您所拥有的有关事件的每个信息既不需要也不建议,但提供基本的细节,并提供几个选择,以便下一步去哪里可以缩短您的响应的初始发现阶段。
送给正确的人
警报如果无法采取行动,就没有用处。常常,一个警报是否可以采取行动取决于响应个人所拥有的知识、经验和允许水平。对于某些规模的组织来说,在某些情况下决定适当的人或组发送消息是简单的,在其他情况下则是模糊的。
调用转换应该包括足够的能力的人来避免疲劳和警报疲劳,最好是你的警报系统包括一个机制来安排调用转换,但如果没有,你可以根据你的时间表手动开发程序来旋转警报联系人。
升级计划是确保事件传递给正确的人的第二种工具. 如果您有员工每天24小时覆盖您的系统,最好将监控系统生成的警报发送给交换员工,而不是调用轮回。
结论
在本指南中,我们讨论了监控和警报在真实系统中是如何工作的。我们开始研究监控系统的不同部分是如何工作的,以满足组织的意识和响应需求。我们讨论了黑色和白色监控之间的差异,作为思考不同警报线索的框架。之后,我们讨论了不同类型的警报,以及如何最好地与适当的警报媒体匹配事件严重性。