Open falcon 监控系统各模块的说明

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
• 高可用：整个系统无核心单点，易运维，易部署，可水平扩展
  等特点。

这是官方给出的各模块图：

如下是我自己画出的各模块图：

然后介绍一下图中的我们常用到的几个模块：

1. Agent: 是用于采集被部署机器上的监控数据，每隔60秒push给Transfer模块。agent与Transfer建立的是长连接（毕竟每分钟发送一次，短连接开销太大）。每台要被监控的机器都要部署该模块，它消耗的资源很小，不用太担心这一点。同时agent提供了一个http接口/v1/push用于接收用户手工push的一些数据，然后通过长连接迅速转发给Transfer，在实际使用中，我们对于某些自己项目接口的监控就是通过此方式来进行上传的。
2. transfer： 是数据转发服务。它接收agent上报的数据，然后按照哈希规则进行数据分片、并将分片后的数据分别push给graph和judge等组件。
3. graph是存储绘图数据的组件。graph组件 接收transfer组件推送上来的监控数据，同时处理query组件的查询请求、返回绘图数据。
4. query组件，提供统一的绘图数据查询入口。query组件接收查询请求，根据一致性哈希算法去相应的graph实例查询不同监控项的数据，然后汇总拿到的数据，最后统一返回给用户。
5. dashboard是面向用户的查询界面。在这里，用户可以看到push到graph中的所有数据，并查看其趋势图。
6. 邮件短信发送模块，这个组件没有代码，需要各个公司自行提供。监控系统产生报警事件之后需要发送报警邮件或者报警短信，各个公司可能有自己的邮件服务器，有自己的邮件发送方法；有自己的短信通道，有自己的短信发送方法。falcon为了适配各个公司，在接入方案上做了一个规范，需要各公司提供http的短信和邮件发送接口。
7. Sender： 6 中提到各个公司会提供邮件、短信发送接口，但是产生了报警之后就立马调用这些接口发送报警，是不合适的。因为这些接口可能无法处理巨大的并发量，而且接口本身的处理速度可能也比较慢，这会拖慢我们的处理逻辑。所以一个比较好的方式是把邮件、短信发送这个事情做成异步的。Sender提供一个短信redis队列，提供一个邮件redis队列。当有短信要发送的时候，直接将短信内容写入短信redis队列即可，当有邮件要发送的时候，直接将邮件内容写入邮件redis队列。针对每个队列，后面有一个预设大小的worker线程池来处理。有了队列的缓冲，即便某个时刻产生了大量报警，造成邮件、短信发送的突发流量，也不会对邮件、短信发送接口造成冲击。
8. Fe 这是Go版本的UIC，也是一个统一的web入口，因为监控组件众多，记忆ip、port去访问还是比较麻烦。fe像是一个监控的hao123.就是为了用户使用方便配置的一个web浏览器操作界面。
9. Portal 是用来配置报警策略的,和HBS 一起描述。
10. HBS(Heartbeat Server)：
    
    • Portal的数据库中有一个host表，维护了公司所有机器的信息，比如hostname、ip等等。HBS第一个功能：agent发送心跳信息给HBS的时候，会把hostname、ip、agent version、plugin version等信息告诉HBS，HBS负责更新host表。
    • Agent只采集用户配置的监控项。比如用户配置了对某个机器80端口的监控，我们才会去采集这个机器80端口的存活性。那agent如何知道自己应该采集哪些端口和进程呢？向HBS要，HBS去读取Portal的数据库，返回给agent。
    • Judge需要获取所有的报警策略，让Judge去读取Portal的DB么？不太好。因为Judge的实例数目比较多，如果公司有几十万机器，Judge实例数目可能会是几百个，几百个Judge实例去访问Portal数据库，也是一个比较大的压力。既然HBS无论如何都要访问Portal的数据库了，那就让HBS去获取所有的报警策略缓存在内存里，然后Judge去向HBS请求。这样一来，对Portal DB的压力就会大大减小。
11. Judge Judge用于告警判断，agent将数据push给Transfer，Transfer不但会转发给Graph组件来绘图，还会转发给Judge用于判断是否触发告警。因为监控系统数据量比较大，一台机器显然是搞不定的，所以必须要有个数据分片方案。Transfer通过一致性哈希来分片，每个Judge就只需要处理一小部分数据就可以了。所以判断告警的功能不能放在直接的数据接收端Transfer，而应该放到Transfer后面的组件里，就有了Judge.
12. Links是为报警合并功能写的组件。如果你不想使用报警合并功能，这个组件是无需安装的。一般不会用到。
13. alarm模块是处理报警event的，judge产生的报警event写入redis，alarm从redis读取处理，报警event的处理逻辑并非仅仅是发邮件、发短信这么简单。为了能够自动化对event做处理，alarm需要支持在产生event的时候回调用户提供的接口；有的时候报警短信、邮件太多，对于优先级比较低的报警，希望做报警合并，这些逻辑都是在alarm中做的。

当然还有其他的模块，因为open falcon 具有很强大的扩展性，通过不同的组件来实现不同的监控要求，以上各部分是open falcon 的主要模块吧，监控的数据主流程所在。

如果有其他的问题请参考官方文档。