开源监控解决方案OpenFalcon系列(一)

OpenFalcon是由小米的运维团队开源的一款企业级、高可用、可扩展的开源监控解决方案，，在众多开源爱好者的支持下，功能愈来愈丰富，文档更加的完善，OpenFalcon 已经成为国内最流行的监控系统之一。小米、美团、金山云、快网、宜信、七牛、又拍云、赶集、滴滴、金山办公、爱奇艺、一点资讯、快牙、开心网、借贷宝、百度、迅雷等公司使用，若是关注招聘网站的话会发现很是多的岗位要求熟悉openfalcon，这也意味着OpenFalcon的使用很是普遍。仍是很是值得花费一些精力去研究一下Openfalcon的架构以及使用等知识。

官网：http://www.open-falcon.org/

GitHub 地址：https://github.com/open-falcon

文档地址：https://book.open-falcon.org/zh_0_2/

API文档：http://open-falcon.org/falcon-plus/

Openfalcon是采起了先后端分离的架构，后端用Go语言开发，前端用Python开发。编译后的后端程序运行时，再也不须要Go语言环境，直接将可执行文件拷贝到某台机器上面运行就能够了，而前端是须要python环境。当机器数量比较大的时候，通常会预先将Agent安装到机器上(物理机标准化装机时安装，虚拟机能够封装到镜像中，私有云或者公有云都支持主要都是网络问题)。当Agent运行时就会上报数据。

Openfalcon架构：

整个后端采用模块化设计，包含agent、aggregator、alarm、api、gateway、graph、hbs、judge、nodata、transfer等模块。接下来再介绍一下每一个模块的功能和特色。

(1) agent： 用于采集机器负载监控指标，好比cpu.idle、load.1min、disk.io.util等等，每隔60秒push给Transfer。agent与Transfer创建了长链接，数据发送速度比较快，agent提供了一个http接口/v1/push用于接收用户手工push的一些数据，而后经过长链接迅速转发给Transfer。agent是须要部署到全部要被监控的机器上，好比公司有10万台机器，那就要部署10万个agent。agent自己资源消耗不多，不用担忧。小米开源的Agent只包含Linux，汽车之家等公司相继开源了Windows的Agent。

   被监控机Agent提供一个默认监听的1988端口的HTTP服务，提供了一个UI设计不错的Web界面，在该页面上可以展现内核、运行时间、主机名、负载状况、内存使用，磁盘使用等基础监控数据。此外还提供了一些接口，经过这些接口获取一些基础监控数据。

（2）aggregator 集群聚合模块。聚合某集群下的全部机器的某个指标的值，提供一种集群视角的监控体验。这种视角下能更好的体现整个集群的某个监控指标，可是该模块目前不是很是完善，咱们在生产环境中没并无使用该模块。

（3）alarm 是处理报警event的，judge产生的报警event写入redis，alarm从redis读取处理，报警event的处理逻辑并不是仅仅是发邮件、发短信这么简单。为了可以自动化对event作处理，alarm须要支持在产生event的时候回调用户提供的接口；有的时候报警短信、邮件太多，对于优先级比较低的报警，但愿作报警合并，这些逻辑都是在alarm中作的。

  在配置报警策略的时候配置了报警级别，好比P0/P1/P2等等，每一个及别的报警都会对应不一样的redis队列 alarm去读取这个数据的时候但愿先读取P0的数据，再读取P1的数据，最后读取P5的数据，由于但愿先处理优先级高的。因而：用了redis的brpop指令。

 注意事项：alarm是个单点。对于未恢复的告警是放到alarm的内存中的，alarm还须要作报警合并，故而alarm只能部署一个实例。后期须要想办法改进。

报警合并：若是某个核心服务挂了，可能会形成大面积报警，为了减小报警短信数量，咱们作了报警合并功能。把报警信息写入links模块，而后links返回一个url地址给alarm，alarm将这个url连接发给用户，这样用户只要收到一条短信（里边是个url地址），点击url进去就是多条报警内容。

highQueues中配置的几个event队列中的事件是不会作报警合并的，由于那些是高优先级的报警，报警合并只是针对lowQueues中的事件。若是全部的事件都不想作报警合并，就把全部的event队列都配置到highQueues中便可

（4）api组件，提供统一的restAPI操做接口。好比：api组件接收查询请求，根据一致性哈希算法去相应的graph实例查询不一样metric的数据，而后汇总拿到的数据，最后统一返回给用户。具体的能够参考http://api.open-falcon.org 的接口文档，注意有模板用户、管理等接口，支持post、get等方法。

（5）gateway 模块主要是为了解决机房分区，试用与异地多活、混合云、多云环境的解决方案。Falcon多数据中心时，提供数据路由功能。多IDC时，可能面对 "分区到中心的专线网络质量较差&公网ACL不通" 等问题。这时，能够在分区内部署一套数据路由服务，接收本分区内的全部流量(包括全部的agent流量)，而后经过公网(开通ACL)，将数据push给中心的Transfer。以下图， 

   从client端的角度来看，gateway和transfer提供了彻底一致的功能和接口。只有遇到网络分区的状况时，才有必要使用gateway组件。服务启动后，能够经过日志查看服务的运行状态，日志文件地址为./var/app.log。能够经过调试脚本./test/debug查看服务器的内部状态数据，如 运行 bash ./test/debug 能够获得服务器内部状态的统计信息。

gateway组件，部署于分区中。单个gateway实例的转发能力，为 {1核, 500MB内存, Qps不小于1W/s}；官方建议，一个分区至少部署两个gateway实例，来实现高可用。在咱们内部新加坡、雅加达、华盛顿、深圳、广州、北京等公有云区域。每一个区域部署一个gateway（2C4G），而后分别经过跨区域带宽将数据回传到咱们上海、杭州IDC内。

（6）graph 是存储绘图数据、历史数据的组件。graph组件 接收transfer组件推送上来的监控数据，同时处理query组件的查询请求、返回绘图数据。

（7）hbs(Heartbeat Server) 心跳服务器，公司全部agent都会连到HBS，每分钟发一次心跳请求。

  Portal的数据库中有一个host表，维护了公司全部机器的信息，好比hostname、ip等等。这个表中的数据一般是从公司CMDB中同步过来的。可是有些规模小一些的公司是没有CMDB的，那此时就须要手工往host表中录入数据，这很麻烦。因而咱们赋予了HBS第一个功能：agent发送心跳信息给HBS的时候，会把hostname、ip、agent version、plugin version等信息告诉HBS，HBS负责更新host表。

    falcon-agent有一个很大的特色，就是自发现，不用配置它应该采集什么数据，就自动去采集了。好比cpu、内存、磁盘、网卡流量等等都会自动采集。咱们除了要采集这些基础信息以外，还须要作端口存活监控和进程数监控。那咱们是否也要自动采集监听的端口和各个进程数目呢？咱们没有这么作，由于这个数据量比较大，汇报上去以后用户大部分都是不关心的，太浪费。因而咱们换了一个方式，只采集用户配置的。好比用户配置了对某个机器80端口的监控，咱们才会去采集这个机器80端口的存活性。那agent如何知道本身应该采集哪些端口和进程呢？向HBS要，HBS去读取Portal的数据库，返回给agent。

以后咱们会介绍一个用于判断报警的组件：Judge，Judge须要获取全部的报警策略，让Judge去读取Portal的DB么？不太好。由于Judge的实例数目比较多，若是公司有几十万机器，Judge实例数目可能会是几百个，几百个Judge实例去访问Portal数据库，也是一个比较大的压力。既然HBS不管如何都要访问Portal的数据库了，那就让HBS去获取全部的报警策略缓存在内存里，而后Judge去向HBS请求。这样一来，对Portal DB的压力就会大大减少

hbs是能够水平扩展的，至少部署两个实例以保证可用性。通常一个实例能够搞定5000台机器，因此说，若是公司有10万台机器，能够部署20个hbs实例，前面架设lvs，agent中就配置上lvs vip便可。

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

   由于监控系统数据量比较大，一台机器显然是搞不定的，因此必需要有个数据分片方案。Transfer经过一致性哈希来分片，每一个Judge就只须要处理一小部分数据就能够了。因此判断告警的功能不能放在直接的数据接收端：Transfer，而应该放到Transfer后面的组件里。

Judge监听了一个http端口，提供了一个http接口：/count，访问之，能够得悉当前Judge实例处理了多少数据量。推荐的作法是一个Judge实例处理50万~100万数据，用个5G~10G内存，若是所用物理机内存比较大，好比有128G，能够在一个物理机上部署多个Judge实例。

（9）nodata  用于检测监控数据的上报异常。nodata和实时报警judge模块协同工做，过程为: 配置了nodata的采集项超时未上报数据，nodata生成一条默认的模拟数据；用户配置相应的报警策略，收到mock数据就产生报警。采集项上报异常检测，做为judge模块的一个必要补充，可以使judge的实时报警功能更加可靠、完善。

    此功能仍是可能会出现较多的误报现象，例如网络异常，致使数据没法上传，这时候就会检测到数据异常。 

（10）transfer transfer是数据转发服务。它接收agent上报的数据，而后按照哈希规则进行数据分片、并将分片后的数据分别push给graph&judge等组件。

以上内容是falcon后端程序中比较核心的模块，同时也能够根据本身的需求去定制一些模块。