当前位置: 首页 > 工具软件 > Falcon > 使用案例 >

open-falcon模块介绍

仲孙兴旺
2023-12-01

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

 类似资料: