开篇

https://book.open-falcon.org/zh_0_2/

图解

从这张图中可以发现，主要的组件有：falcon-agent、transfer、hbs（hearbeat server）、Judge、Graph、alarm、剩下的就是常见的redis、和mysql了
每台服务器，都有安装falcon-agent，falcon-agent是一个golang开发的daemon程序，用于自发现的采集单机的各种数据和指标，只要安装了falcon-agent的机器，就会自动开始采集各项指标，主动上报；open-falcon，采用和opentsdb相同的数据格式：metric、endpoint加多组key value tags，

{
    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: net.port.listen,
    endpoint: open-falcon-host,
    tags: port=3306,
    value: 1,
    timestamp: `date +%s`,
    counterType: GAUGE,
    step: 60
}

通过这样的数据结构，我们就可以从多个维度来配置告警，配置dashboard等等。agent发送给谁呢？看图，是给了transfer，transfer接收客户端发送的数据，做数据规整，检查之后，转发到多个后端系统去处理。其中，transfer会根据一致性hash算法，进行数据分片，来达到后端业务系统的水平扩展。
transfer 提供jsonRpc接口和telnet接口两种方式，transfer自身是无状态的，挂掉一台或者多台不会有任何影响，同时transfer性能很高，每分钟可以转发超过500万条数据。transfer目前支持的业务后端，有三种，judge、graph、opentsdb。judge是我们开发的高性能告警判定组件，graph是我们开发的高性能数据存储、归档、查询组件，opentsdb是开源的时间序列数据存储服务。可以通过transfer的配置文件来开启。
transfer的数据来源，一般有三种：

• falcon-agent采集的基础监控数据
• falcon-agent执行用户自定义的插件返回的数据
• client library：线上的业务系统，都嵌入使用了统一的perfcounter.jar，对于业务系统中每个RPC接口的qps、latency都会主动采集并上报
  说明：上面这三种数据，都会先发送给本机的proxy-gateway，再由gateway转发给transfer。
  再展开细说，报警判定，是由judge组件来完成。用户在web portal来配置相关的报警策略，存储在MySQL中。heartbeat server 会定期加载MySQL中的内容。judge也会定期和heartbeat server保持沟通，来获取相关的报警策略。
  heartbeat sever不仅仅是单纯的加载MySQL中的内容，根据模板继承、模板项覆盖、报警动作覆盖、模板和hostGroup绑定，计算出最终关联到每个endpoint的告警策略，提供给judge组件来使用。
  transfer转发到judge的每条数据，都会触发相关策略的判定，来决定是否满足报警条件，如果满足条件，则会发送给alarm，alarm再以邮件、短信、米聊等形式通知相关用户，也可以执行用户预先配置好的callback地址。
  在页面上也完成了诸多人性化操作：
  用户可以很灵活的来配置告警判定策略，比如连续n次都满足条件、连续n次的最大值满足条件、不同的时间段不同的阈值、如果处于维护周期内则忽略 等等。
  另外也支持突升突降类的判定和告警。