OpenFalcon简介

转载请注明出处：http://blog.csdn.net/u012842205/article/details/79397658

一、说明

    OpenFalcon（官方网站）是一款企业级、高可用、可扩展的开源监控解决方案。此项目最初由小米公司发起，小米运维团队从互联网公司的需求出发，根据多年的运维经验，结合SRE、SA、DEVS的使用经验和反馈，开发的一套面向互联网的企业级开源监控产品，最新版本为v2.0。目前有几十家公司不同程度使用OpenFalcon作为分布式系统的监控解决方案。

其优点如下:

1. 采集器自动发现，支持falcon-agent、snmp、支持用户主动push数据、用户自定义插件。

2. 支持每个周期上亿次的数据采集、告警判定、历史数据存储和查询。

3. 高效的分区、支持监控策略模板、模板继承和覆盖、多种告警方式、支持告警回调。

4. 单节点能支持200万metric的上报、归档、存储。

5. 其存储采用rrdtool归档，秒级返回上百个metric一年的历史数据。

6. 多维度的数据展示，可由用户自定义Screen。

7. 通过各种插件目前支持Linux、Windows、Mysql、Redis、Memache、RabbitMQ和交换机监控。

二、OpenFalcon监控范围

    OpenFalcon支持系统基础监控，第三方服务监控，JVM监控，业务应用监控。

    基础监控指Linux平台的系统指标监控，包括CPU、Load、内存、磁盘、IO、网络等，这些指标由OpenFalcon的agent节点直接支持，无需插件。

    JVM监控主要通过插件完成，插件通过JVM开放的JMX通信端口，获取到JVM参数指标，并推送到agent节点，再由agent发送到OpenFalcon。

    第三方服务监控指一些常见服务监控，包括MySQL、Redis、Nginx等，OpenFalcon官网提供了很多第三方服务的监控插件，也可以自己实现插件，定义采集指标。而采集到的指标，也是通过插件先发送给agent，再由agent发送到OpenFalcon。

    业务应用监控主要是监控企业自主开发的应用服务。由企业根据业务需要定义采集指标，自实现插件。将获取到的采集指标发送到agent，再由agent发送到OpenFalcon。

三、OpenFalcon数据流向

    常见的OpenFalcon包含transfer、hbs、agent、judge、graph、API几个进程。但没有提供用户界面。用户界面的解决方案是OpenFalcon官方提供的Dashboard，由python编写的一个Web服务。Dashboard调用OpenFalcon的API节点REST，完成用户认证，查询历史等操作。

    以下是各个节点的数据流向图，主数据流向是agent -> transfer -> judge/graph：

(1)agent

    agent进程部署在需要监控的服务器上，即是说，公司有一百台服务器需要监控，则需要分别在每台服务器上部署agent进程。agent只能运行于Linux节点，关于windows平台的监控，官方提供了Windows版本的agent。本文中所有提到agent的地方都指Linux平台的agent。

    部署好agent后，能自动获取到系统的基础监控指标，并上送到transfer。agent与transfer建立了TCP长连接，每隔60秒发送一次数据到transfer。另外，agent提供一个简单的监控界面，默认的端口号为1988，且提供一个REST接口，供用户程序将采集到的指标发送给OpenFalcon。所有自实现的插件都使用这个REST接口上送数据。

(2)transfer

    transfer进程负责分发从agent上送的监控指标数据，并根据哈希分片，将数据分发给judge进程和graph进程，供告警判定和绘图。

(3)graph

    graph进程接收从transfer推送来的指标数据，并绘图存储。graph也为API进程提供查询接口，供绘图查询。

(4)API

    API进程是面向用户及Dashboard的REST接口程序。用户可以通过API提供的接口查询OpenFalcon的绘图数据。用户请求的绘图数据查询会由API代理，向graph进程请求，获取到数据后返回给用户。除了绘图数据，也包含主机的一些档案数据，具体的API接口见官方API文档。

(5)hbs

    hbs是Heartbeat server的缩写。设计初衷是用于接收agent的心跳，判定agent存活性。agent发送的心跳会携带被监控主机的IP、hostname等信息，这些档案信息将汇总给hbs节点。hbs会将这些档案信息存储到portal数据库。供Dashboard及API查询使用。另外，由于hbs将要访问portal数据库，这个数据库中存储了告警策略信息，而judge进程需要这些策略，为了缓解judge直接访问MySQL而带来的数据库访问压力，judge改从hbs的RPC接口访问告警策略信息。

(6)judge

    judge进程用于判断transfer推送的指标数据是否触发告警。若触发了告警，judge将会产生告警事件，这些告警事件会写入Redis（使用Redis消息队列），供处理告警事件的Alarm进程转发告警消息，或是Email，或是手机短信等。

(7)Alarm

    Alarm进程监听Redis中的消息队列，并将judge产生的告警事件转发给微信、短信和邮件三种REST接口。REST接口才是具体的发送动作。另外，关于告警，每条告警策略都会定义不同的优先级，Redis中的消息队列也按优先级划分。Alarm不仅消费告警事件，优先级比较低的报警，其合并逻辑都是在alarm中做，所以目前Alarm进程只能部署一个实例。已经发送出去的告警事件，Alarm将会负责写入MySQL。

四、其他问题

    笔者尚未找到数据存储在什么位置。OpenFalcon采用rrdtool存储框架。直接以文件的形式存储在磁盘上，目前我找到了一些rrdtool文件，按照哈希分片的前缀进行目录划分，但由哪个进程存储，尚不得而知。官方文档也没有数据存储方面的说明。