一、数据获取组件falcon-agent
1）自动获取方式：
每台服务器，都有安装falcon-agent，falcon-agent是一个golang开发的daemon程序，用于自发现的采集单机的各种数据和指标，这些指标包括不限于以下几个方面，共计200多项指标。 只要安装了falcon-agent的机器，就会自动开始采集各项指标，主动上报，不需要用户在server做任何配置（这和zabbix有很大的不同），这样做的好处，就是用户维护方便，覆盖率高。当然这样做也会server端造成较大的压力，不过open-falcon的服务端组件单机性能足够高，同时都可以水平扩展，所以自动多采集足够多的数据，反而是一件好事情，对于SRE和DEV来讲，事后追查问题，不再是难题。
2）手动上传方式：
falcon-agent提供了一个proxy-gateway，用户可以方便的通过http接口，push数据到本机的gateway，gateway会帮忙高效率的转发到server端。
数据结构data-model:{metric: load.1min,endpoint: open-falcon-host,tags: srv=falcon,idc=aws-sgp,group=az1, value: 1.5,timestamp: `date +%s`,counterType: GAUGE,step: 60}
其中，metric是监控指标名称，endpoint是监控实体，tags是监控数据的属性标签，counterType是Open-Falcon定义的数据类型(取值为GAUGE、COUNTER)，step为监控数据的上报周期，value和timestamp是有效的监控数据。
3)监控信息
机器负载信息
这部分比较通用，我们提供了一个agent部署在所有机器上去采集。不像zabbix，要采集什么数据需要在服务端配置，falcon无需配置，只要agent部署到机器上，配置好heartbeat和Transfer地址，就自动开始采集了，省去了用户配置的麻烦。目前agent只支持64位Linux，Mac、Windows均不支持。
硬件信息
硬件信息的采集脚本由系统组同学提供，作为plugin依托于agent运行，plugin机制介绍请看这里。 服务监控数据
服务的监控指标采集脚本，通常都是跟着服务的code走的，服务上线或者扩容，这个脚本也跟着上线或者扩容，服务下线，这个采集脚本也要相应下线。公司里Java的项目有不少，研发那边就提供了一个通用jar包，只要引入这个jar包，就可以自动采集接口的调用次数、延迟时间等数据。然后将采集到的数据push给监控，一分钟push一次。目前falcon的agent提供了一个简单的http接口，这个jar包采集到数据之后是post给本机agent。 向agent推送数据的一个简单例子，如下： curl -X POST -d '[{"metric": "qps", "endpoint": "open-falcon-graph01.bj", "timestamp": 1431347802, "step": 60,"value": 9,"counterType": "GAUGE","tags": "project=falcon,module=graph"}]' http://127.0.0.1:1988/v1/push 各种开源软件的监控指标
这都是大用户，比如DBA自己写一些采集脚本，连到各个MySQL实例上去采集数据，完事直接调用server端的jsonrpc汇报数据，一分钟一次，每次甚至push几十万条数据，比较好的发送方式是500条数据做一个batch，别几十万数据一次性发送。
二、心跳组件falcon-hbs
1)功能
处理agent心跳请求，并将agent信息（ip、hostname、agent_version、plugin_version）等信息入库（portal库）
为agent提供执行run api的白名单
为agent 提供执行的plugin插件
为agent提供需要监控的进程和端口
缓存监控策略，为judge 提供告警阈值
2)数据处理
agent和HBS 通信
agent上报自己的信息至HBS
HBS 会检查agent信息是否存在，如果存在，则只更新数据，不存在则插入agent信息，如果agent的
host配置sync，则不处理。此时hostname 为唯一索引。
查询agent 的所需要监控的进程、端口和执行的plugin脚本，返回给agent
judge 和HBS通信 HBS会每分钟查询数据库，并将策略缓存至内存
三、数据转发组件transfer
1）功能
接收agent上报的数据，然后按照哈希规则进行数据分片、并将分片后的数据分别push给graph&judge等组件
负责数据转发，接受agent上报的数据，然后使用一致性hash规则对数据进行分片，最后将分片后的数据分别转发至judge，graph
对接收到的数据进行合法性校验、规整
针对每个后端实例维护一个RPC连接池
准备内存Queue中转监控数据，可以保证后端judge和graph平稳接收数据
根据一致性hash规则将Queue中的数据转发给judge和graph
当后端宕机时做少量缓存，提供重试机制，但是容队列爆满之后会造成内存溢出
2)transfer的数据来源
falcon-agent采集的基础监控数据
falcon-agent执行用户自定义的插件返回的数据
client library：线上的业务系统，都嵌入使用了统一的perfcounter.jar，对于业务系统中每个RPC接口的qps、latency都会主动采集并上报
说明：上面这三种数据，都会先发送给本机的proxy-gateway，再由gateway转发给transfer。
3）数据转发流程
初始化连接池
模块启动时，会根据配置初始化RPC连接池。Judge模块初始化的连接池个数为Judge.Cluster数量。从代码中可以看出，每一个Cluster中的Judge模块进行的是单点部署。Graph模块初始化的连接池个数为Graph.Cluster中的地址数。
初始化发送队列
当Transfer接收到数据之后，跟根据一致性哈希确定节点，传递给相应的发送队列，队列中再去发送至Judge以及Graph模块。其中，发送给Judge模块一份数据（因为只配置了一个Judge实例），发送给所有属于该节点的所有Graph模块一份数据。 发送队列和连接池是一一对应的。
PS：transfer 会根据endpoint、metric、tag进行一致性hash计算key，保证多台transfer时同样的key可以发送至同一个graph，保证数据连续性
四、存储绘图数据组件graph
1)功能
接收transfer组件推送上来的监控数据，同时处理api组件的查询请求、返回绘图数据。
存储agent push的数据
为query 提供查询数据接口
参考RRDtool的理念，在数据每次存入的时候，会自动进行采样、归档。在默认的归档策略，一分钟push一次的频率下，
历史数据保存5年。同时为了不丢失信息量，数据归档的时候，会按照平均值采样、最大值采样、最小值采样存三份。
用户在查询某个metric，在过去一年的历史数据时，Graph会选择最合适的采样频率，返回采样过后的数据，提高了数据查询速度。
2)查询过程
根据endpoint和counter，从索引中获取dsType和step
生成md5 ：endpoint + counter => md5
从indexedItemCache查找md5对应的item
没有找到的话，从DB中进行查找
开始/结束时间，按照step进行取整
根据endpoint、counter、dsType、step，获取对应的RRD文件名
从cache中查询数据 ：根据cache key获取items和flag 从历史数据中查询数据，如果cfg支持migrate，以及判断查询数据不在这个Graph实例，则从其它Graph实例进行查询。
否则，查询本地rrd文件 将cache中的数据，以及rrd/其它Graph实例中的数据，进行合并
五、告警判断组件judge
1）功能
Judge用于告警判断，agent将数据push给Transfer，Transfer不但会转发给Graph组件来绘图，还会转发给Judge用于判断是否触发告警。
Judge模块的功能是通过从HBS上同步告警的strategys(告警策略)，及Expression，用来在接收transfer上报过来的数据时，对数据进行检测，每收到一条上报的数据，就去匹配对应的strategy和Expression是否满足条件，判断是否需要向redis发送告警。
因为监控系统数据量比较大，一台机器显然是搞不定的，所以必须要有个数据分片方案。Transfer通过一致性哈希来分片，每个Judge就只需要处理一小部分数据就可以了。所以判断告警的功能不能放在直接的数据接收端：Transfer，而应该放到Transfer后面的组件里。
其实说它没有状态也不太合适，judge 内存里也存了几个点。比如某一台机器 cpu.idle 数据上来之后，连续 3 ~ 5 次达到一个特定阀值才去报警，而不是达到阀值立马报警。像 CPU，是一直都忙碌状态才去报警，Judge 判断的时候它是判断多个点。
产生报警之后，还有一些后续处理，比如对这个报警事件做一个判断，上次产生事件是什么状态，他是第几次报警，是不是达到了最大报警次数不能再报了，避免重复报警给处理人员造成干扰。一般大家都设置报警 3 次。
因此报警事件需要记录一个状态，标记是否健康，如果有问题，记录当前是第几次。Judge 状态存在数据库，虽然 1 亿条数据上来，实际上报警数据不多，可能只有 10 万条数据级别，因此可以存入数据库，这样 Judge 就剥离了报警事件状态。 虽然 Judge 内存当中还存一些前面所说数据状态，但也不是一个大问题。因为监控数据是源源不断上来，即使丢掉一些状态，新的 Judge 实例很快就会又填充数据。
2）处理流程
1、通过RPC注册两个方法，一个是ping,返回一个nil的返回值，另一个是send，处理transfer发送过来的数据。
2、对于transfer发送过来的每个监控数据，都会生成一个pk（对数据的endpoint,metric,tags进行字符串拼接，之后再用md5进行hash，生成一个hash值）。通过pk的前两位hash值，去HistoryBigMap中找到对应的值，调用PushFrontAndMaintain。（HistoryBigMap的结构会在后面进行讲解）
3、调用PushFrontAndMaintain会去JudgeItemMap中找到pk对应的值（链表）
4、Judge方法会调用CheckStrategy方法以及CheckExpression方法对新监控数据和历史数据进行处理。
六、告警组件alarm
1)设计初衷
报警event的处理逻辑并非仅仅是发邮件、发短信这么简单。为了能够自动化对event做处理，alarm需要支持在产生event的时候回调用户提供的接口；有的时候报警短信、邮件太多，对于优先级比较低的报警，希望做报警合并，这些逻辑都是在alarm中做的。
我们在配置报警策略的时候配置了报警级别，比如P0/P1/P2等等，每个及别的报警都会对应不同的redis队列 alarm去读取这个数据的时候我们希望先读取P0的数据，再读取P1的数据，最后读取P5的数据，因为我们希望先处理优先级高的。于是：用了redis的brpop指令。
已经发送的告警信息，alarm会写入MySQL中保存，这样用户就可以在dashboard中查阅历史报警，同时针对同一个策略发出的多条报警，在MySQL存储的时候，会聚类；历史报警保存的周期，是可配置的，默认为7天。
2）报警合并
如果某个核心服务挂了，可能会造成大面积报警，为了减少报警短信数量，我们做了报警合并功能。把报警信息写入dashboard模块，然后dashboard返回一个url地址给alarm，alarm将这个url链接发给用户，这样用户只要收到一条短信（里边是个url地址），点击url进去就是多条报警内容。
highQueues中配置的几个event队列中的事件是不会做报警合并的，因为那些是高优先级的报警，报警合并只是针对lowQueues中的事件。如果所有的事件都不想做报警合并，就把所有的event队列都配置到highQueues中即可
七、插件介绍
1、mymom 用来监控mysql，采集hostB上的mysql实例指标
2、logdog 用来做关键字监控，如日志监控
3、redis-monitor 用来监控redis的各项指标
4、ngx_metric 主要用来监控nginx
5、urlooker 监控web服务可用性及访问质量（返回状态码检测，页面响应时间检测，页面关键词匹配检测，带cookie访问，）