大数据下的技术运营（三）——报警系统设计与实现

本文是《大数据下的技术运营》系列稿件的第三篇，前两篇文稿为：

《大数据下的技术运营（一）—— 监控系统概览篇 》

《大数据下的技术运营（二）—— 数据采集系统设计与实现》

开发背景

TalkingData 拥有千台以上服务器的大数据业务集群，所以对于系统的监控能力、指标的实时分析和历史报警信息追查也就有一定的要求，而且由于机器数量较多，我们也需要一些灵活的报警策略应对不同的情况。

目前业界已经存在很多的报警系统，例如：Zabbix, Nagios, Promethus 等等，但是以上系统分别有一些不足，Zabbix 对于监控项目的批量修改会比较麻烦，Nagios 看不到历史数据，只能看到报警事件，很难追查故障原因，Promethus 缺少 Web 操作界面，不太易于使用。

我们之前版本的监控系统有诸多弊病，主要是非常难于部署安装，而且对于更改某一台主机的监控项会非常苦难，所以最后选择了用 Go 语言开发下一个版本的监控系统，主要是因为可以满足用户的定制化的需求并且具备高易用性。 此外，相比一些付费的报警系统，自研报警系统又可以节约成本，加上我们都是由 Go 语言开发的系统，开发好的项目直接编译成二进制文件后会非常容易部署。

报警服务架构

(点击放大图像)

(点击放大图像)

流程图

报警控制器（controller）

controller 会循环定时地从 MySQL 数据库里加载报警策略，然后根据策略生成一个个的具体监控任务，每个任务对应一台主机或者一台虚拟机的指标逻辑表达式，再将这些监控任务存进任务池中，随后由 inspector 来读取并执行相应任务后返回给 controller 检测结果，并且 controller 会根据结果标注的级别将不同级别的结果存入不同的结果池。多个 Goroutines 会从结果池中读取出结果并判定是否触发报警以及是否触发恢复通知。

报警检验器（inspector）

inspector 与 controller 建立了 TCP 长连接，inspector 会定时地去 controller 拉取配置以及相关监控任务（同样有心跳的功能），拿到配置信息和任务以后，inspector 会根据策略里具体配置的监控策略去 OpenTSDB 中拉取监控数据，比较监控阈值并产生结果，然后将产生的结果通过长连接传送回 controller。inspector 可以水平扩展，如果生成的监控任务很多时，可以水平地扩展 inspecctor 来环节监控压力。

报警策略

高效的监控报警系统应当有一个灵活的、清晰的报警策略。在制定报警策略时我们有四个重要的考量如下：

1. 对报警进行分级、分类。
2. 在添加报警时要能够批量添加、批量更改
3. 针对某一个或者某一组设备要有具备单独抽离控制的能力
4. 当发生大范围产生报警时，要具备有能力对报警进行合并，避免报警干扰。

为了满足以上的需求，我们抽象出了一种“策略”的概念，策略本身可以根据作用范围分成不同级别：分别是“全局策略”、“主机组策略”、“主机策略”。

范围大的策略可以批量添加报警，范围小的策略可以针对个别设备脱离本身的策略并添加独特报警。每一个策略需要被赋予一个名字，对应的就是一类报警。同类的策略也可以划分级别，不同级别的策略产生的任务被存储在不同的 channel。低级别报警需要达到一定数量才会合并成一条发出告警，如此以避免报警过多的干扰。

报警流程

1. 事件判断

每一个报警策略可以包含多个条件。条件之间可以通过表达式“||”， “&&”，“（）”，“==”等连接，当多个条件表达式的最后值为 true 的时候，会触发某个动作。具体的动作可以是发送报警，执行某个恢复动作。策略可以选择性的作用在多个主机组和多个主机上，也可以作用在某个特定的主机组或者主机上。

2. 条件判断

每个策略有多个条件，每个条件包括指标（metric）、标签（tags）、比较表达式、阈值以及报警方法。

举例说明，一个指标上可以包括多个 tag, 这些 tag 可以根据不同维度去抓取数据，得到数据后再根据比较方法和比较表达式计算最终的一个布尔值。

3. 报警处理

产生报警时可以依据所属组与所属主机按照报警级别进行展示，报警级别可以分成高、中、低三种级别。报警可以被知悉，当点击了报警知悉后，该报警就不会再被发送。知悉后的报警可以被关闭，关闭后可以输入一些备注来说明对于此次报警的具体处理方式。

报警算法

监控系统本身要监控许多种服务指标以及系统指标，而且各种指标的变化和监控的重点也是不一样的，针对不同的指标采用合适的报警算法，可以大大提高监控的准确性，降低误报率。目前 TalkingData 应用的几种算法都是比较普遍的，主要有最大值、最小值、环比、TopN、BottomN，下面我分别介绍一下这几种算法的具体实现和应用场景。

最大值

在某一段时间范围内，采集多个数据点，从中找出一个最大值，用最大值和我们预先定义的阈值进行比较，用此种方式来判断是否触发报警。举例说明，当某块磁盘的使用率超过了某一个阈值，我们就需要马上提示这台主机的磁盘空间不足，以避免影响业务服务的正常运转。

最小值

和最大值正好相反，从采集的数据中找到一个最小值并和阈值一起进行比较。主要的应用场景可以是监控某一服务的进程数，当进程数小于某个阈值时必须触发报警。

环比

环比是当前时间段的数据集的平均值 (data2) 与之前某一段时间数据集的平均值 (data1) 进行差值然后除以之前数据集的平均值，公式是：(data2 – data1 / data1) * 100。此种算法的具体应用场景是针对那些平时指标曲线比较稳定坡度不是很大服务。当某一个时间段的数据坡度明显增高或者降低时，说明服务一定遇到了很大的波动，那么就要触发相应的报警提示。

TopN

此种算法是将数据集中的每一个点都和阈值进行比较，当所有的点都达到阈值时才触发报警。CPU 使用率在某一时间点突然增高其实是一种很常见的情况，这种情况是 TopN 具体的应用场景之一；不能因为某一个时间点 CPU 突然增高就立刻发送报警，这样会产生很多无用的误报。

BottomN

此种方法与 TopN 正好相反，这里就不作赘述。

报警算法可以根据不同的业务需求去实现，你总会找到一个适合你业务的报警算法。减少误报、准确性高，这才是报警算法的终极目标。

总结

报警系统需要设计的灵活一些，存储监控数据的数据库可以进行灵活的适配与切换，针对个别监控组与主机可以灵活的进行监控调整。另外，对于监控系统自身的监控我们目前还没有支持，但是我们未来会加上自身健康状态监控与查询，报警控制器将会提供了一个 Http Server 用来查看每个连接到 inspector 的运行状态，运行在哪个宿主机节点上，而且还可以设置各个 inspector 的监控任务吞吐量，针对于个别性能较好的节点，可以通过控制器提供的 rest api 提高指定 inspector 的任务吞吐量，这样整个监控系统看起来就会更健壮一些。

作者介绍

马超，TalkingData 运维部研发工程师，精通 Golang 和 Python，五年技术工作经历，曾从事手机游戏服务端研发， 技术运营研发工程师。关注 平台稳定性（监控，问题发现及响应）和资源充分利用（虚拟化，容器）。

感谢木环对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。