open-falcon模块介绍

一、数据获取组件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访问，）

转载于:https://my.oschina.net/u/3384249/blog/1550701