针对大数据集群，监控报警系统发展的历史及业务背景

关于监控报警方面我也思考过很多次，因为监控报警现在已经是互联网公司的常见产品了。

大数据的监控和报警只是一系列报警规则的一个子集，尽管这个子集非常复杂。

有趣的是，报警系统的底层数据存储引擎也属于大数据存储的范畴。 所以我打算从这个大纲开始这篇文章：

大数据集群监控报警特点

监控报警系统的发展历史和业务背景

监控报警系统通用架构

监控报警系统详解

总结

大数据集群监控报警特点

图1：基于大数据集群不同特性的监控报警特点

对于大数据基础设施这样的部门，不可能配备专门的测试工程师。 那么这么多的机器、服务、应用如何才能良好运行呢？

这就需要一个强大的“自动化监控报警系统”。 对于监控和报警，不同的公司有不同的解决方案。

对于大公司、小公司、初创公司，他们都会根据自己的实际情况选择适合自己的解决方案。

监控报警系统的发展历史及业务背景

市场上的监控报警系统五花八门，但市场越是眼花缭乱，你越需要擦亮眼睛，看清它的本质，剥去它的骨头，找到适合自己的解决方案。

网上有很多关于公司内部监控报警系统的文章。 他们都提到了自己的监控系统的实现，但都是直接解释实现的细节，而没有深入到骨架或后台。

感觉对于新程序员来说会有点生硬，对于想了解监控报警系统内部工作原理的人来说架构逻辑不够清晰。 因此，我写了这篇既讲背景又讲骨架的文章。

首先介绍一些背景知识，让我们谈谈软件工程。 很久以前，软件开发技术团队在做迭代开发时，一般都会经历以下的开发流程：

需求分析

原型/功能设计

测试用例设计（TDD测试驱动开发）

开发人员完成功能并部署测试环境

根据测试用例进行测试

如果在测试过程中发现错误，则会回滚到开发并再次修复。

如果测试没有发现bug，就会启动生产环境

当用户真正在网上发现该Bug时，好心用户会报告该Bug并联系客服人员。

这个过程可能会导致什么问题？ 一般都是简单的“显性”Bug，比如“网站关键页面打不开”、“网站订单支付功能老是失效”等错误。

用户和公司都可以在较短的时间内发现问题，然后将问题重新整理、报告为Bug、修复、回滚。

还有一些“隐性”的bug，比如“网站越来越慢”、“支付功能需要30秒才成功”、“有时成功、有时失败”、“短信验证码一周后变得更难”产品上线后“只需25秒即可发送到客户手机上。”

此类问题有时并不影响业务逻辑的正常运行，但系统内部肯定出现了问题。

有时日积月累，更多的问题就会逐渐暴露出来，最终导致核心业务宕机； 有时甚至上线后产品性能本身就会很差，因为上线了某种“代码/配置”的改变。 这种“隐性”的bug也会影响用户体验。

测试发现显性错误，那么隐性错误呢？ 随着互联网的发展，各大互联网公司对业务稳定性、可靠性的要求越来越高。

但公司业务线不断增加，测试工程师不可能无休无止地进行手工测试，24小时盯着产品。

作为一家公司，我们希望用户不会报告此类隐含的错误。 最好是内部“快速”发现问题，“自动”发现问题，比“用户”更早发现问题。 这迫使创建“自动定期在线测试”。

“早期自动化测试”仅发生在软件发布之前。 例如，一个新功能开发并提交后，公司的持续集成工具会自动触发测试用例运行。

用例包括开发人员的“单元（白盒）测试”和测试人员编写的“脚本（黑盒）测试”。 只有所有要求都通过后，才能部署到“生产”环境。

这样，大部分“显性”的bug都能被发现，但很难发现“隐性”的bug。 如果某些程序出现内存泄漏，它们不会立即崩溃。 可能要运行一周甚至一个月才会出现问题。

“自动定期在线测试”解决了隐含的错误。 产品上线后，不断对线上环境的各项指标进行长期观察，并定期进行判断，发现异常情况。

如果存在潜在的异常，那么某些监控指标就会出现问题。 当一些异常指标暴露出来时，如果能立即联系相应产品的“负责人”并立即进行整改，从长远来看，产品的声誉将会得到很大的提高。

例如：某电商网站支付页面响应速度持续超过5s，远大于长期平均水平（2s）。 当这种现象连续出现5次时，就会向该区域的研发人员发出警报，发现该程序有资源。 泄漏导致机器变慢，然后重启了一些服务，保证用户速度提升，然后立即组织功能，最终解决了问题。

监控报警系统通用架构

之前讲过“自动化定期在线测试”的历史原因和背景。 看来，这是时代和科技世界发展引发的“技术更替”。

在下文中，我们将“自动定期在线测试”系统称为“监控报警”系统。 因为它代替了人“监控”，代替了测试工程师“报告问题”。

图2：监控报警信息流

我认为监控报警分为四大部分：

数据采集

存储数据（时间序列的存储）

报警规则

警报行为

下图的监控系统是基本骨架。 如果再细化一下，整个架构图会是这样的：

图3：监控报警系统架构图

监控报警系统详解

数据采集

收集数据，我觉得这篇经典的《，》（）是一篇开启了新时代“数据驱动”监控和运营思维的博文。 你可以阅读它。

这里提到的想法也符合我这个系列文章的目的：让每个人的决策都基于数据。

文章提到，企业级监控数据通常包括以下三类：

网络数据包括骨干交换机、核心交换机等硬件设备。

服务器数据包括服务器CPU、内存、硬盘的各种使用数据。

应用程序数据。

应用数据是三者中最难的，但也是最重要的。 应用数据是与业务逻辑密切相关的数据。 如果业务逻辑发生变化，应用程序数据的集合也会发生变化。

在应用程序数据领域，有一个名为“应用程序数据收集标准”的开源项目。

我在这里简单提一下：

累计值(): 1 | C

服务时间（）glork：320 | 女士 | @0.1

第 333 章 G

字符串的第一部分是“”。 用冒号分隔的左边部分是“”，右边部分是“”，竖线右边的部分是“数据类型”。

存储数据

监控和报警的数据都是围绕“监控指标值随时间变化的趋势”的目标来设计的。 每个监控指标数据序列天然都是“按时间排序”的，这是它的特点。

业界用于存储这种数据结构的工具称为“时间序列数据库”。 这是一个专有数据库，而不是像 RDBMS（关系数据库）那样的通用 SQL 数据库。

市场上有很多基于时间序列的数据库。 无论底层数据结构实现是什么样的，时序存储的本质数据结构始终是：

地图>

不同的底层实现对上述数据结构的某些点有不同的扩展，例如：

s1。 分片逻辑的实现不同：选择的分片是一致性哈希还是余数哈希。

s2的实施是不同的，本质上是一个排序序列。

s3。 阅读和写作偏好略有不同。

这里我不重点介绍各个时序数据库及其底层数据结构的具体实现。

在选择技术时，需要同时考虑技术痛点和业务痛点。 只有业务场景确定了，才能进行技术选型。

那么根据业务场景，还有另外几个选择点：

s4。 会无限增加吗？

s5。 保留时间跨度是多长？

s6。 上层业务报警有多重要？

为了解决s1-s6的技术选型问题，我举一些例子来说明：

是否无限增加以及保留多长时间

对于专有系统，即解决特定领域问题的时间序列存储，密钥不会无限增长。

例如，我们管理的套房——或者有自己的监控和报警系统。

它们都将数据存储在本地磁盘上，相当于本地数据库。 单机版数据库的问题是受到单机硬盘物理上限的限制。

好在技术栈的监控指标有限且收敛，这些数据大部分只需要保留1个月。 因此，“监控系统”的单机存储空间是可控的。

专有系统必须服务于成熟的“有凝聚力的产品”。 通用监控报警系统，关键将无限增长。

正如“，”中提到的，公司各个业务线团队都会将自己的应用数据发送到统一的指标数据存储中。

随着业务线和监控指标的增长，时间序列存储的压力无限增大，数据的保存期限不确定，可能是无限的（每个应用都有其特殊性，不可估量）。 这就要求底层数据存储必须支持“无限水平扩展”。

实施和读写能力偏好

即全局排序映射表，其实现必须根据报警监控的实际需要而定。

由于专有系统指标有限，数据采集频率也不是特别高，所以同时写入的数据量应该是可控的。 这时候B+Tree和B+Tree都是不错的实现方法。

一般系统中，监控指标会无限增加，部分指标的采集要求频率可达数十毫秒。 此类高频并发写入需求一般采用lSM Tree来实现。

上层业务报警（HA&高可用）有多重要

在任何时候，监控和报警系统必须可用，并且必须能够容忍某些机器的故障。 不能因为某台机器或者某个进程挂了，就导致整个监控报警系统宕机。

单点故障：

监控报警系统用于“观察公司内所有业务是否正常运行”。 所有产品的第一根救命稻草在于“监控报警”系统。

它已经关闭了，并且不再报告该公司所有产品的问题。 因此，基于单机版本数据存储的时间序列无法满足企业级需求。 请务必选择高可用HA（High）的数据存储解决方案。

对于小型初创公司来说，在业务初期和快速成长阶段，可以暂时放弃高可靠可用性，首先采用“磁盘Raid、定时备份、数据库级主备”等简单易实现的技术-从机切换”，快速满足轻负载需求。 业务需求的大小。

最后，附上时间序列数据库摘要中引用的一些论文和文章：

维基：时间

报警规则

报警规则模块，首先自然是个性化的。 为什么？ 报警规则显然与每家公司的具体业务相关。

这些规则基于对历史数据的分析和测量。 这就涉及到公司业务的个性化。 本文不会过多讨论个性化业务的细节。

我们来看看报警规则的常见技术点：

高规则周期检查

企业级应用强调高可用性和HA，必须避免单点故障（SPOF）。 如果“报警规则模块”出现问题，仍然会导致“监控报警”系统出现故障。

一般来说，报警规则是周期性触发的。 因此，需要一个“类似Cron Job”的调度程序。

此类调度系统的HA设计可以参考“”和“”：

：

：

调度系统的HA设计主要分为“规则数据库高可用”和“调度服务器高可用”两个方面：

数据库高可用是通过Slave的主从来实现的。

为了调度的高可用，如果有状态，就使用zk/etcd来实现高可用； 如果没有状态，则启动多个调度服务器。 根据调度规则制定一定的分片策略并不困难。

报警规则定义

在观察了一系列监控报警产品后，我大致总结了两种定义和实现“报警规则”的方式：

基于“正则表达式”。

直接基于“脚本和编程”。

基于正则表达式：熟悉表达式语言后更容易编写，但灵活性较差。 复杂的报警规则实现起来比较困难，一般适合简单的报警规则。

例如，当一两个观察指标达到阈值时触发，如下所示：

： 规则 |

图4：根据规则设置警报示例

还有基于可视化配置规则的配置，例如：3.2。

图5：可视化规则配置

4.0之后，还有基于规则的简单报警功能：&规则指南，如下图：

图 6：.0 基于规则的警报 UI .1

图 7：.0 基于规则的警报 UI .2

基于“脚本/编程”，这种类型的规则定义提供了无限的灵活性。 因为“可编程”意味着能够“做”。

但也有一些缺点，比如：它引入了另一个外部依赖：代码管理库，这意味着必须为另一个系统做高可用HA，一般用于公司内部的代码管理。

当你想要快速修改报警规则时，过程会比较慢，因为需要经过代码修改、Merge、最后。

报警规则“脚本”定义示例：从两个数据源采集数据，根据自定义规则判断指标是否异常。 如果出现异常，首先进行“重启”行为，缓解线上压力，然后向相关工程师发送报警。 追根溯源。

这种稍微复杂的报警规则可以用编程脚本毫无压力地实现，但基于规则语言来实现报警就比较困难甚至不可能。

图8：基于“脚本”的报警规则，定义函数

图9：基于“脚本和编程”的报警规则示例

报警行为

你可能会问，报警有什么好说的？ 无非就是报警规则触发后，通过电话、微信、短信、邮件等媒体找到正确的负责人。 这听起来很简单。

好吧，我们继续思考更丰富的应用场景：比如我们的架构组有HDFS、Yarn、Hive、HBase、Spark、Hue……好吧，我们不说了。

这么多部件，一个人能操作和维护吗？ 是否有必要将工作分摊给小组中的多人？ 每个人一个星期？

健康检测警报每5分钟发生一次。 每次检测失败都会报警吗？ 会不会有误报？

在第一次异常报警后，工程师已经开始排除问题。 现在连续第二次、第三次检测到异常，是否需要连续打电话打扰工程师？ 那么，您连续抑制警报多少次？

哪些警报非常重要，必须日夜打电话通知； 哪些是比较重要的，白天可以打电话，晚上可以发邮件或者短信先通知问题； 哪些是次要的，您只能发送电子邮件。

有时检测程序也会因为一些“噪音”而出现抖动。 例如，检测网页的打开速度限制为2ms，但一次访问却因为网络链接的抖动达到了50ms。 我们应该直接报警吗？ 难道是连续3-5次的数据都超标了？ 报警之前需要确认问题吗？

报警行为软件分为“自研”和“第三方”两条路径：

自主研发，该路径适合报警行为规则强而复杂的大公司。 包括报警行为规则的复杂性和报警介质的复杂性。

每个公司使用的内网办公聊天软件和电子邮件系统可能会有所不同，并且会有独特的场景需要集成。

每个公司、每个团体的报警行为可能有所不同。 有的要求一天24小时，有的只需要在白天发送邮件，有的甚至只需要在工作日白天发送邮件。

第三方软件，中小型公司、初创公司比较适合使用第三方软件。 据我所知，湾区大部分公司都使用它。 您可以参考链接了解详情：

该产品尚未汉化，市场上还没有杀手级的本土软件。 我四处寻找，找到了该公司的One-Alert()。 我尝试了演示，效果非常好。

个人看法：这方面的需求会越来越大。 希望国内有靠谱的、正派的企业，共同推动国内“监控报警”市场的发展。

总结

我整理了一个表格来描述“监控报警”领域常见的开源产品范围：

大家在做技术选型的时候，一定要着眼长远，多思考未来的需求，而不是只注重快速交付。 同时，我们也希望中国出现关注“报警行为”的企业。