监控系统概述

在监控系统领域，相信大家都经历过 Zabbix 的时代；在公司刚起步，机器数量不多时，Zabbix 可以很好的满足我们的需求，但是随着业务的发展，Zabbix 的存储会成为主要的性能瓶颈，从而引发很多问题，增加运维成本。

近些年来，随着互联网技术的不断发展，技术架构的不断演进，监控领域有两个我值得推荐的开源系统：一个是小米出品的 Open-Falcon，一个是基于 Google Borgmon 的开源实现 Prometheus。

今天主要介绍下 Open-Falcon。

Open-Falcon 有如下特点：

1. 强大灵活的数据采集：自动发现，支持falcon-agent、snmp、支持用户主动push、用户自定义插件支持、opentsdb data model like（timestamp、endpoint、metric、key-value tags）
2. 水平扩展能力：支持每个周期上亿次的数据采集、告警判定、历史数据存储和查询
3. 高效率的告警策略管理：高效的portal、支持策略模板、模板继承和覆盖、多种告警方式、支持callback调用
4. 人性化的告警设置：最大告警次数、告警级别、告警恢复通知、告警暂停、不同时段不同阈值、支持维护周期
5. 高效率的graph组件：单机支撑200万metric的上报、归档、存储（周期为1分钟）
6. 高效的历史数据query组件：采用rrdtool的数据归档策略，秒级返回上百个metric一年的历史数据
7. dashboard：多维度的数据展示，用户自定义Screen
8. 高可用：整个系统无核心单点，易运维，易部署，可水平扩展
9. 开发语言： 整个系统的后端，全部golang编写，portal和dashboard使用python编写。

简而言之：Open-falcon 是一个模块化、高可用、高性能、支持水平扩展的监控告警系统，支持机器监控、业务监控、各种开源软件的监控。

架构

Architecture

Agent

数据采集组件

部署在业务机器上，主要作用：

1. 自动采集预先定义的各种采集项（机器级别的监控指标）
2. agent 还提供一个 HTTP 接口（/v1/push），用于接收用户自定义上报数据

每隔60秒，通过 JsonRPC push 数据到 Transfer 模块（使用长连接）。

Transfer

数据转发服务

主要作用：

1. 接收 agent 上报的数据
2. 按照哈希规则进行数据分片，并将分片后的数据分别 push 给 graph、judge 等组件

Graph

存储绘图数据、历史数据

主要作用：

1. 接口 transfer 推送数据
2. 处理 API 组件的查询请求、返回绘图数据

API

绘图数据的查询接口

主要作用：根据一致性哈希算法去相应的 graph 实例查询不同监控项的数据，汇总后返回

Dashboard

面向用户的查询界面

Judge

告警判断

因为数据量太大，此组件放在 transfer 组件之后，这样每个 judge 只需要处理一小部分数据；主要作用：

1. 接口 transfer 推送数据
2. 分析数据，判断是否触发告警，需要告警则写入 redis

部署一个 judge 实例处理50万~100万数据，用个5G~10G内存。

Alarm

处理告警事件

主要作用：

1. 从 redis 读取数据，触发动作（短信、邮件、回调等）
2. 告警合并
3. 已经发送的告警信息存入 MySQL，默认存7天

alarm是个单点，因为未恢复的告警是放到alarm的内存中的，alarm还需要做报警合并。需要做好存活监控。

HBS

心跳服务器(Heartbeat Server)

至少部署两个实例以保证可用性，一般一个实例可以搞定5000台机器；主要作用：

1. 所有 agent 都会连到 HBS，每分钟发一次心跳请求，并告知 agent 应该采集哪些端口和进程
2. 维护业务机器的信息（host 表）
3. 告知 judge 报警策略

Nodata

检测监控数据的上报异常

主要作用：配置了nodata的采集项超时未上报数据，nodata生成一条默认的模拟数据

Aggregator

集群聚合

主要作用：聚合某集群下的所有机器的某个指标的值，提供一种集群视角的监控体验

Task

定时任务

主要作用：

1. index更新。包括图表索引的全量更新 和 垃圾索引清理。
2. falcon服务组件的自身状态数据采集。定时任务采集了transfer、graph、task这三个服务的内部状态数据。
3. falcon自检控任务

设计理念

数据采集

1. 制定接口规范，以此接入各种监控数据
2. agent 自发现采集各种 Linux 性能指标，无需配置
3. 由 HBS 下发各种采集指标、策略
4. 支持 plugin；用户把插件提交到指定的 git repo，server端提供一个配置，哪些机器应该执行哪些插件，通过 HBS 把这个信息分发给 agent，agent 每隔一段时间去 git pull 这个 git repo，采集脚本就完成了分发。执行周期通过解析文件名来执行：60_action.sh，60s 执行一次。脚本执行完了，把输出打印到stdout，agent 截获之后 push 给 server

Tag

Tag 是一种聚合手段，可以用更少的配置覆盖更多的监控项。例如：

1
2
3
4
5
6
7
8
9

{
    "endpoint": "qd-sadev-falcon-judge01.hd",
    "metric": "latency",
    "tags": "department=sadev,project=falcon,module=judge,method=falcon.judge.rpc.send",
    "value": 10.2,
    "timestamp": 1427204756,
    "step": 60,
    "counterType": "GAUGE"
}

如果我们这么配置：latency/department=sadev all(#2) > 20，意味着对sadev这个部门的所有接口的latency都做了策略配置。

模板继承

同一个部门的机器，根据不同的业务对监控策略的要求是不一样的，比如业务 A 复杂高，load.1min > 10 就报警，业务 B 复杂低，load.1min > 5 就报警。若不支持模板继承，则需要配置两份策略，而模板继承就减少了此类工作量。

数据存储

Open-falcon 把数据按照用途分成两类，一类是用来绘图的，一类是用户做数据挖掘的。关于绘图数据，在数据每次存入的时候，会自动进行采样、归档。我们的归档策略如下，历史数据保存5年。同时为了不丢失信息量，数据归档的时候，会按照平均值采样、最大值采样、最小值采样存三份。

对于原始数据，transfer会打一份到hbase，也可以直接使用opentsdb

使用示例

部署

参见小米公司部署Open-Falcon的一些实践经验

监控网络

dashboard
Screen

配置告警

template

上报接口状态

上报状态码、耗时等，可监控接口的健康、性能等。
falcon

可以做的改进

参见Mt-Falcon——Open-Falcon在美团点评的应用与实践

参考资料

1. Open-Falcon 官方文档