002-open-falcon插件

不打扰是莪最后的温柔 提交于 2019-12-16 18:10:40

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>>

open-falcon插件

逻辑图

相关插件名称

transfer

transfer是数据转发服务。它接收agent上报的数据,然后按照哈希规则进行数据分片、并将分片后的数据分别push给graph&judge等组件。

检查服务状态是否正常
curl -s "127.0.0.1:6060/health"
启动服务
./open-falcon start transfer
停止服务
./open-falcon stop transfer
查看服务
./open-falcon monitor transfer

后续插件的相关查看命令大家举一反三

graph

graph是存储绘图数据的组件。graph组件 接收transfer组件推送上来的监控数据,同时处理api组件的查询请求、返回绘图数据。

api

api组件,提供统一的restAPI操作接口。比如:api组件接收查询请求,根据一致性哈希算法去相应的graph实例查询不同metric的数据,然后汇总拿到的数据,最后统一返回给用户

HBS

心跳服务器,公司所有agent都会连到HBS,每分钟发一次心跳请求。 Portal的数据库中有一个host表,维护了公司所有机器的信息,比如hostname、ip等等。这个表中的数据通常是从公司CMDB中同步过来的。但是有些规模小一些的公司是没有CMDB的,那此时就需要手工往host表中录入数据,这很麻烦。于是我们赋予了HBS第一个功能:agent发送心跳信息给HBS的时候,会把hostname、ip、agent version、plugin version等信息告诉HBS,HBS负责更新host表。 falcon-agent有一个很大的特点,就是自发现,不用配置它应该采集什么数据,就自动去采集了。比如cpu、内存、磁盘、网卡流量等等都会自动采集。我们除了要采集这些基础信息之外,还需要做端口存活监控和进程数监控。那我们是否也要自动采集监听的端口和各个进程数目呢?我们没有这么做,因为这个数据量比较大,汇报上去之后用户大部分都是不关心的,太浪费。于是我们换了一个方式,只采集用户配置的。比如用户配置了对某个机器80端口的监控,我们才会去采集这个机器80端口的存活性。那agent如何知道自己应该采集哪些端口和进程呢?向HBS要,HBS去读取Portal的数据库,返回给agent。 之后我们会介绍一个用于判断报警的组件:Judge,Judge需要获取所有的报警策略,让Judge去读取Portal的DB么?不太好。因为Judge的实例数目比较多,如果公司有几十万机器,Judge实例数目可能会是几百个,几百个Judge实例去访问Portal数据库,也是一个比较大的压力。既然HBS无论如何都要访问Portal的数据库了,那就让HBS去获取所有的报警策略缓存在内存里,然后Judge去向HBS请求。这样一来,对Portal DB的压力就会大大减小。

judge

Judge用于告警判断,agent将数据push给Transfer,Transfer不但会转发给Graph组件来绘图,还会转发给Judge用于判断是否触发告警。 因为监控系统数据量比较大,一台机器显然是搞不定的,所以必须要有个数据分片方案。Transfer通过一致性哈希来分片,每个Judge就只需要处理一小部分数据就可以了。所以判断告警的功能不能放在直接的数据接收端:Transfer,而应该放到Transfer后面的组件里。

Alarm

alarm模块是处理报警event的,judge产生的报警event写入redis,alarm从redis读取处理,并进行不同渠道的发送。 报警event的处理逻辑并非仅仅是发邮件、发短信这么简单。为了能够自动化对event做处理,alarm需要支持在产生event的时候回调用户提供的接口;有的时候报警短信、邮件太多,对于优先级比较低的报警,希望做报警合并,这些逻辑都是在alarm中做的。 我们在配置报警策略的时候配置了报警级别,比如P0/P1/P2等等,每个及别的报警都会对应不同的redis队列 alarm去读取这个数据的时候我们希望先读取P0的数据,再读取P1的数据,最后读取P5的数据,因为我们希望先处理优先级高的。于是:用了redis的brpop指令。 已经发送的告警信息,alarm会写入MySQL中保存,这样用户就可以在dashboard中查阅历史报警,同时针对同一个策略发出的多条报警,在MySQL存储的时候,会聚类;历史报警保存的周期,是可配置的,默认为7天。

Nodata

nodata用于检测监控数据的上报异常。nodata和实时报警judge模块协同工作,过程为: 配置了nodata的采集项超时未上报数据,nodata生成一条默认的模拟数据;用户配置相应的报警策略,收到mock数据就产生报警。采集项上报异常检测,作为judge模块的一个必要补充,能够使judge的实时报警功能更加可靠、完善。

Aggregator

集群聚合模块。聚合某集群下的所有机器的某个指标的值,提供一种集群视角的监控体验。

参考文档: https://blog.csdn.net/qq_27384769/article/details/79569813 https://blog.csdn.net/jorson2000a/article/details/81359804

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!