宜信大数据：如何快速搭建监控报警系统

作者：宜信大数据创新中心LAIN团队

在系统的开发及运维中，监控报警始终是非常重要的环节。监控报警系统能够帮助开发运维人员及时理解系统的状况，便于出现问题时及时定位，同时可以根据整个监控指标的趋势图规划后续的开发运维计划。本文希望通过介绍宜信大数据创新中心的监控报警系统，给大家快速搭建一套监控报警系统提供一些参考。

基本架构

在宜信大数据创新中心，我们使用了自研开源的基于 Docker 的 PaaS 平台 LAIN 帮助业务快速开发迭代。为了使得整个平台更加稳定，我们也基于一些开源组件构建了一套方便可用的监控报警系统。

通常一套监控报警系统会包括这么几个模块：

1. 指标数据收集
2. 指标数据存储
3. 指标数据展示
4. 监控报警

我们在进行技术选型时主要考虑的是希望各组件专注做一件事情并把它做好。基于这点，我们选择了 collectd 进行数据收集，Graphite 进行数据存储， Grafana 进行数据展示，icinga2 进行监控报警。基本的架构如图所示：

下面我们通过一个例子介绍下各个组件的基本情况：假设我们需要监控某台服务器上8080端口的连接数，并对其设置报警阈值。

数据收集

监控报警系统最基础的一环就是如何对监控指标的相关数据进行收集。我们选用collectd 进行收集。 collectd 的优势包括：

1. 使用 C 编写，性能以及可移植行都非常棒；
2. 插件丰富，支持超过一百种以上插件，各种常见的指标如机器 load、disk usage 等等都能够非常轻松的通过配置相应插件进行收集；
3. 拓展性好，可以通过自定义插件的形式进行一些其他数据收集，比如我们自己也写了一些插件来监控 LAIN 中运行容器的基本状态；

那如果我们想通过 collectd 收集机器 8080 端口的连接数，并将相应数据发送给Graphite。在安装好 collectd 之后只需要在 /etc/collectd.conf 配置文件中加入下列语句即可：

整个配置文件比较好理解，首先声明了机器的主机名，载入 tcpconns 以及 write_graphite 两个插件。

tcpconns配置成了会收集本机的 8080 端口的相关连接信息，如果申明其中的 ListeningPorts 变量为 true 意味着插件会收集本机上所有被 socket 监听的端口，设置为 false 则只会收集指定的端口。

write_graphite配置成使用 tcp 协议将消息发送给 localhost 的 2003 Port，此处 Host 和 Port 指的就是 Graphite 的数据收集模块 carbon-cache 所在的机器的 Hostname 或者 IP 地址以及相应监听的端口。

配置文件中具体配置项的含义以及支持的插件的配置项都可以在 collectd.conf 的 Manpage 中看到。

数据存储

Graphite是一个很受欢迎的指标收集平台。其主要组件包括：

• carbon: 监控数据接收组件
• whisper: 监控数据存储组件
• Graphite     Web: 监控数据查询及展示组件

Carbon

Carbon主要包括三个组件：carbon-cache、carbon-relay 以及 carbon-aggregator。

carbon-cache主要负责接收指标数据，然后定期将接收到的数据写入到磁盘中。同时它还停供了查询接口，可以直接查询位于内存中的还未被写入磁盘的相关热点数据。

给 carbon-cache 发送数据非常简单，如果不用 collectd 的 write_graphite plugin 进行发送，也完全可以通过非常简单的命令给 carbon-cache 发送数据：

echo "foo.bar 1 `date +%s`"| nc localhost 2003

其中主要包括三项：指标名、指标相关数据以及时间戳。

对于一个数据量不大的监控系统来说，其实一个简单的 carbon-cache 实例就已经足够了。但是随着监控指标的增多，仅仅靠一个 carbon-cache 可能会导致 I/O 出现瓶颈。这个时候就需要考虑carbon-relay，可以通过定制相应的规则将服务按一定的规则（比如一致性哈希）发送给后端的多个 carbon-cache。

carbon-aggregator的作用其实与 statsd 相似，主要是起到一个数据归集的作用。一方面可以减轻 carbon-cache 的压力，一方面有些情况下需要进行统计工作，也可以通过 carbon-aggregator进行处理。

Whisper

carbon-cache的数据会从内存中落地到 whisper 中。whisper 是一种基于文件的时间序列型数据库，针对存入其中的每一个指标都会生成一个固定大小的基于时间序列的 .wsp 存储文件。固定大小的一个优势是能够根据需要收集的指标数粗略的估计出总共需要的磁盘空间。

对于大多数指标的监控而言，大家更加关心的是最近一段时间的详细数据，而对于之前的监控数据，只需要能够看到一个大致的趋势就已经足够了。用户可以通过配置文件规定存在于whisper 中的指标的数据精度，设置随着时间的推移慢慢降低存储精度。

比如我们可以在配置 carbon-cache 时，在配置文件 storage-schemas.conf 中配置成如下形式：

[default]

pattern = .*

retentions = 1m:7d,10m:30d,30m:1y

其中 pattern 匹配指标的名字，retentions 指定这个指标应该保留多久。此配置信息则表示相应的符合条件的指标数据，1 分钟精度的会保留 7 天，之后降为 10 分钟精度，保留 30 天，再之后降为 30 分钟精度，保留 1 年。

当然，除了 [default] 你也可以根据某些特定的指标设置合适的相应存储方式。但是这些设置都是只会对新创建的 wsp 文件有效，已有的文件的存储策略需要通过 whisper-resize 进行更改。

Graphite-Web 与 Graphite-API

Graphite-Web主要是提供监控指标的对外查询接口以及指标展示功能，但是因为相对来说比较臃肿，也可以选择 Graphite-API 进行替代。

Graphite-API相对于 Graphite-Web 来说更加轻量级，不提供指标展示功能，只提供了相关的查询接口。Graphite-API 的主要缺点是不能支持多个 carbon-cache 后端，但是对于数据量不大的监控还是足够用了的。

配置 Graphite-API 也相当简单，安装好后只需配置/etc/graphite-api.yaml 文件，指定whisper 所在的目录以及 carbon-cache 所提供的查询地址即可：

指标展示

Graphite-Web提供的展示功能并不是特别的方便，因此我们选用 Grafana 进行展示。大家可以在 http://play.grafana.org/ 这里试玩下，体验下 grafana 提供的展示能力。

Grafana主要拥有如下优势：

1. Dashboard 配置方便，可以随意通过拖拽方式进行变动，调换；配置好之后还能够导出模板分享给他人使用；
2. 支持多种后端，包括 Graphite, Elasticsearch, InfluxDB 等等，也可以通过编写 plugin 支持一些特别的后端；
3. 支持认证，支持 LDAP、Basic Auth；

在 Grafana 中配置展示 Graphite 的数据非常简单，我们只需在 DataSource 处选择 Graphite，然后填好 Graphite-Web 或者 Graphite-API 所对应的 url 即可。

接下来通过一些简单的网页点击选择即可展示出来相应的数据了，如图：

Grafana在推出 4.0 的时候已经能够配置报警了，对于一些简单的监控报警其实也可以通过 Grafana 进行配置。

监控报警

在监控报警这方面，我们选择的工具是 icinga，主要包括 icinga2 以及 icinga2web 两个组件。

icinga2主要采用 C++ 编写，旨在替代 Nagios 以及 icinga1，可以复用 Nagios 所有的插件。它提供了非常方便的 API 供调用，同时拓展性、伸缩性以及性能方面也都非常的优秀。

icingaWeb2主要给 icinga2 提供了 UI，在其中我们能够非常方便的查看所有的监控项、报警接收人、监控的状态等等，同时因为每次报警信息都存入到了数据库中，我们也能在 UI 上非常方便的去查看所有的报警历史。

我们开源了一个构建 icinga2 docker 镜像的仓库：github.com/laincloud/centos-lain-icinga2 其中加入了一些我们写的拓展脚本，包括从 graphite 中读取数据，根据相应的阈值进行报警。我们也提供了一些常用的报警通知脚本，包括 sms,mail, bearychat, slack 等等。

另一方面 icinga2 并没有提供非常好的，配置报警的功能，所有的监控项需要通过配置文件进行配置，当需要管理大量的监控项时则会显得不那么方便，LAIN 自研了一个组件 Hagrid 可以提供给开发人员自定义监控项，目前支持的监控项包括 Graphite 中收集的指标项，以及 TCP 连接的相关监控。用户自定义好配置项后成功保存后则会调用相应的 icinga2 API 生成 icinga2 相关配置文件。

一些经验总结

我们基于以上组件封装成了两个LAIN 应用：Hedwig 以及 Hagrid。分别提供了指标收集展示及监控报警功能，简单搭建好 LAIN 系统后即可直接部署，欢迎大家试玩。

在整个监控系统的使用过程中，我们也积累了一些经验，抽取几点比较我们觉得比较有普遍性的也跟大家简单介绍下：

1. collectd 中收集数据的时间间隔建议设置成与 whisper 的最大精度时间一致，比如都是60s。因为过于频繁的数据收集可能会使得数据在 carbon-cache 的内存中产生堆积，从而大大增加内存占用量。
2. 另外一个可能使得 carbon-cache 内存占用量升高的原因是由于 carbon-cache 写入 whisper 的速度过慢导致数据在     carbon-cache 中出现堆积。carbon-cache 有个配置参数 MAX_UPDATES_PER_SECOND 表示每秒更新多少指标，在实际过程中，需要根据指标数来确定该数值，数值较高虽然会减少内存占用，但是磁盘 IO 会变的更高，同时这个值也会影响到新创建的监控指标落地的时间。
3. 在生产中，有可能某些服务或者机器废弃后不会再往 carbon 中发送指标数据，但是其所占的 whisper 文件大小并不会减少，长此以往还是一件挺占磁盘空间的事情，因此建议可以定期对长期不更新的 whisper 文件进行清除。
4. 对监控报警系统的监控也是一件非常重要的事情！

总结来说，我们通过一些非常优秀的开源组件以及自定义的配置构建了一套开箱即可用的监控报警系统，希望能给大家在构建自己的监控报警系统提供一定的参考。

本文链接：http://www.yunweipai.com/11037.html