open-falcon的学习

• 强大灵活的数据采集：自动发现，支持falcon-agent、snmp、支持用户主动push、用户自定义插件支持、opentsdb data model like（timestamp、endpoint、metric、key-value tags）

• 水平扩展能力：支持每个周期上亿次的数据采集、告警判定、历史数据存储和查询

• 高效率的告警策略管理：高效的portal、支持策略模板、模板继承和覆盖、多种告警方式、支持callback调用

• 人性化的告警设置：最大告警次数、告警级别、告警恢复通知、告警暂停、不同时段不同阈值、支持维护周期

• 高效率的graph组件：单机支撑200万metric的上报、归档、存储（周期为1分钟）

• 高效的历史数据query组件：采用rrdtool的数据归档策略，秒级返回上百个metric一年的历史数据

• dashboard：多维度的数据展示，用户自定义Screen

• 高可用：整个系统无核心单点，易运维，易部署，可水平扩展

• 开发语言： 整个系统的后端，全部golang编写，portal和dashboard使用python编写。

每台服务器，都有安装falcon-agent，falcon-agent是一个golang开发的daemon程序，用于自发现的采集单机的各种数据和指标，这些指标包括不限于以下几个方面，共计200多项指标。

• CPU相关

• 磁盘相关

• IO

• Load

• 内存相关

• 网络相关

• 端口存活、进程存活

• ntp offset（插件）

• 某个进程资源消耗（插件）

• netstat、ss 等相关统计项采集

• 机器内核配置参数

Data Model是否强大，是否灵活，对于监控系统用户的“使用效率”至关重要。比如以zabbix为例，上报的数据为hostname（或者ip）、metric，那么用户添加告警策略、管理告警策略的时候，就只能以这两个维度进行。举一个最常见的场景：

hostA的磁盘空间，小于5%，就告警。一般的服务器上，都会有两个主要的分区，根分区和home分区，在zabbix里面，就得加两条规则；如果是hadoop的机器，一般还会有十几块的数据盘，还得再加10多条规则，这样就会痛苦，不幸福，不利于自动化（当然zabbix可以通过配置一些自动发现策略来搞定这个，不过比较麻烦）。

open-falcon，采用和opentsdb相同的数据格式：metric、endpoint加多组key value tags，举两个例子：

通过这样的数据结构，我们就可以从多个维度来配置告警，配置dashboard等等。 备注：endpoint是一个特殊的tag。

transfer，接收客户端发送的数据，做一些数据规整，检查之后，转发到多个后端系统去处理。在转发到每个后端业务系统的时候，transfer会根据一致性hash算法，进行数据分片，来达到后端业务系统的水平扩展。

transfer 提供jsonRpc接口和telnet接口两种方式，transfer自身是无状态的，挂掉一台或者多台不会有任何影响，同时transfer性能很高，每分钟可以转发超过500万条数据。

transfer目前支持的业务后端，有三种，judge、graph、opentsdb。judge是我们开发的高性能告警判定组件，graph是我们开发的高性能数据存储、归档、查询组件，opentsdb是开源的时间序列数据存储服务。可以通过transfer的配置文件来开启。

transfer的数据来源，一般有三种：

1. falcon-agent采集的基础监控数据

2. falcon-agent执行用户自定义的插件返回的数据

3. client library：线上的业务系统，都嵌入使用了统一的perfcounter.jar，对于业务系统中每个RPC接口的qps、latency都会主动采集并上报

说明：上面这三种数据，都会先发送给本机的proxy-gateway，再由gateway转发给transfer。

Alerting

报警判定，是由judge组件来完成。用户在web portal来配置相关的报警策略，存储在MySQL中。heartbeat server 会定期加载MySQL中的内容。judge也会定期和heartbeat server保持沟通，来获取相关的报警策略。

heartbeat sever不仅仅是单纯的加载MySQL中的内容，根据模板继承、模板项覆盖、报警动作覆盖、模板和hostGroup绑定，计算出最终关联到每个endpoint的告警策略，提供给judge组件来使用。

transfer转发到judge的每条数据，都会触发相关策略的判定，来决定是否满足报警条件，如果满足条件，则会发送给alarm，alarm再以邮件、短信、米聊等形式通知相关用户，也可以执行用户预先配置好的callback地址。

用户可以很灵活的来配置告警判定策略，比如连续n次都满足条件、连续n次的最大值满足条件、不同的时间段不同的阈值、如果处于维护周期内则忽略 等等。

+

另外也支持突升突降类的判定和告警。

Query

到这里，数据已经成功的存储在了graph里。如何快速的读出来呢，读过去1小时的，过去1天的，过去一月的，过去一年的，都需要在1秒之内返回。

这些都是靠graph和query组件来实现的，transfer会将数据往graph组件转发一份，graph收到数据以后，会以rrdtool的数据归档方式来存储，同时提供查询RPC接口。

query面向终端用户，收到查询请求后，会去多个graph里面，查询不同metric的数据，汇总后统一返回给用户。

Dashboard

dashboard是面向用户的查询界面。在这里，用户可以看到push到graph中的所有数据，并查看其趋势图

Fe

这是Go版本的UIC，也是一个统一的web入口，因为监控组件众多，记忆ip、port去访问还是比较麻烦。fe像是一个监控的hao123

Portal

Portal是用来配置报警策略的

HBS(Heartbeat Server)

心跳服务器，公司所有agent都会连到HBS，每分钟发一次心跳请求。

Judge

Judge用于告警判断，agent将数据push给Transfer，Transfer不但会转发给Graph组件来绘图，还会转发给Judge用于判断是否触发告警。

Links

Links是为报警合并功能写的组件。如果你不想使用报警合并功能，这个组件是无需安装的。

Alarm

alarm模块是处理报警event的，judge产生的报警event写入redis，alarm从redis读取处理

Task

task是监控系统一个必要的辅助模块。定时任务，实现了如下几个功能：

• index更新。包括图表索引的全量更新 和 垃圾索引清理。

• falcon服务组件的自身状态数据采集。定时任务了采集了transfer、graph、task这三个服务的内部状态数据。

• falcon自检控任务。