码迷,mamicode.com
首页 > 其他好文 > 详细

关于open falcon 与nightingale 的一些调研

时间:2020-06-04 19:34:44      阅读:95      评论:0      收藏:0      [点我收藏+]

标签:体验   趋势   moc   ref   实时   产生   一致性   去除   默认   

针对 open-falcon 与 nightingale 的调研


一、open-falcon

1.1 组件介绍

1.1.1 agent
> agent用于采集机器负载监控指标,比如cpu.idle、load.1min、disk.io.util等等,每隔60秒push给Transfer。agent与Transfer建立了长连接,数据发送速度比较快,agent提供了一个http接口/v1/push用于接收用户手工push的一些数据,然后通过长连接迅速转发给Transfer。

> agent需要部署到所有要被监控的机器上,比如公司有10万台机器,那就要部署10万个agent。agent本身资源消耗很少,不用担心。
1.1.2 transfer
> transfer是数据转发服务。它接收agent上报的数据,然后按照哈希规则进行数据分片、并将分片后的数据分别push给graph&judge等组件。同时 transfer 也支持将数据转发给 opentsdb 和 influxdb,也可以转发给另外一个 transfer。
1.1.3 graph
> graph是存储绘图数据的组件。graph组件 接收transfer组件推送上来的监控数据,同时处理api组件的查询请求、返回绘图数据。
1.1.4 api
> api组件,提供统一的restAPI操作接口。比如:api组件接收查询请求,根据一致性哈希算法去相应的graph实例查询不同metric的数据,然后汇总拿到的数据,最后统一返回给用户。
1.1.5 dashboard
控制台
1.1.6 hbs
> 心跳服务器,公司所有agent都会连到HBS,每分钟发一次心跳请求。

> agent发送心跳信息给HBS的时候,会把hostname、ip、agent version、plugin version等信息告诉HBS,HBS负责更新host表

> hbs是可以水平扩展的,至少部署两个实例以保证可用性。一般一个实例可以搞定5000台机器,所以说,如果公司有10万台机器,可以部署20个hbs实例,前面架设lvs,agent中就配置上lvs vip即可。

> HBS去获取所有的报警策略缓存在内存里
1.1.7 judge
> Judge用于告警判断,agent将数据push给Transfer,Transfer不但会转发给Graph组件来绘图,还会转发给Judge用于判断是否触发告警。

> HBS去获取所有的报警策略缓存在内存里,然后Judge去向HBS请求
1.1.8 alarm
> alarm模块是处理报警event的,judge产生的报警event写入redis,alarm从redis读取处理,并进行不同渠道的发送。
1.1.9 task
task是监控系统一个必要的辅助模块。定时任务,实现了如下几个功能:

> index更新。包括图表索引的全量更新 和 垃圾索引清理。
> falcon服务组件的自身状态数据采集。定时任务了采集了transfer、graph、task这三个服务的内部状态数据。
> falcon自检控任务。
1.1.10 gateway
> 如果您没有遇到机房分区问题,请直接忽略此组件。
1.1.11 nodata
> nodata用于检测监控数据的上报异常
> nodata和实时报警judge模块协同工作,过程为: 配置了nodata的采集项超时未上报数据,nodata生成一条默认的模拟数据;用户配置相应的报警策略,收到mock数据就产生报警。采集项上报异常检测,作为judge模块的一个必要补充,能够使judge的实时报警功能更加可靠、完善。
1.1.12 aggregator
集群聚合模块。聚合某集群下的所有机器的某个指标的值,提供一种集群视角的监控体验。

1.2 流程

技术图片

二、nightingale

2.1 组件介绍

2.1.1 collector
类似于agent ,可以采集机器常见指标,支持日志监控,支持插件机制,支持业务通过接口直接上报数据
2.1.2 transfer
transfer提供rpc接口接收collector上报的数据,然后通过一致性哈希,将数据转发给多台tsdb和多台judge
2.1.3 tsdb
原来的graph组件,用于存储历史数据,支持配置为双写模式提升系统容灾能力,tsdb会把监控数据转发一份给index
2.1.4 index
index是索引模块,替换原来的mysql方案,在内存里构建索引,便于后续数据检索,性能大幅提升
2.1.5 judge
judge是告警引擎,从monapi(portal)同步监控策略,然后对接收到的数据做告警判断,如满足阈值,则生成告警事件推到redis
2.1.6 monapi(alarm)
> monapi(alarm)从redis读取judge生成的事件,进行二次处理,补充一些元信息,生成告警消息,重新推回redis
> 写入event 至mysql
2.1.7 通知消息个组件
各发送组件,比如mail-sender、sms-sender等,从redis读取告警消息,发送告警,抽出各类sender是为了后续定制方便
2.1.8 monapi
monapi集成了原来多个模块的功能,提供接口给js调用,api前缀为/api/portal,数据查询走transfer,干掉了原来的query组件,api前缀为/api/transfer,索引查询的api前缀/api/index,于是,前面搭建nginx,即可通过不同location将请求转发到不同后端

2.2 流程

技术图片

三、对比

3.1 相同点

> nightingale 和 open falcon 再整体流程上较为相似。一些组件只是名称的变化,功能较为类似

3.2 不同点

> 数据存储 graph 在nightingale 中被改为了TSDB 内存存储.提升了数据查询效率(仅存储近几个小时的数据)
> open falcon:alarm 处理报警event 并进行发送; nightingale: monapi(alarm)从redis读取event处理后重新推回redis,再由各发送组件读取告警消息发送
> nighthingale 增加了index索引模块,代替了open falcon mysql方案,由内存中构建索引
> nightingale 将 openfalcon 中的api、uic、dashboard、hbs、alarm 合并为一个模块 monapi,简化部署难度

3.3 nightingale官方对比open-falcon的异同

3.3.1 不同点
> 告警引擎重构为推拉结合模式,通过推模式保证大部分策略判断的效率,通过拉模式支持了nodata告警,去除原来的nodata组件,简化系统部署难度
> 引入了服务树,对endpoint进行层级管理,去除原来扁平的HostGroup,同时干掉告警模板,告警策略直接与服务树节点绑定,大幅提升灵活度和易用性
> 干掉原来的基于数据库的索引库,改成内存模式,单独抽出一个index模块处理索引,避免了原来MySQL单表达到亿级的尴尬局面,索引基于内存之后效率也大幅提升
> 存储模块Graph,引入facebook的Gorilla,即内存TSDB,近期几个小时的数据默认存内存,大幅提升数据查询效率,硬盘存储方式仍然使用rrdtool
> 告警引擎judge模块通过心跳机制做到了故障自动摘除,再也不用担心单个judge挂掉导致部分策略失效的问题,index模块也是采用类似方式保证可用性
> 客户端中内置了日志匹配指标抽取能力,web页面上支持了日志匹配规则的配置,同时也支持读取目标机器特定目录下的配置文件的方式,让业务指标监控更为易用
> 将portal(falcon-plus中的api)、uic、dashboard、hbs、alarm合并为一个模块:monapi,简化了系统整体部署难度,原来的部分模块间调用变成进程内方法调用,稳定性更好
3.3.2 相同点
> 数据模型没有变化,仍然是metric、endpoint、tags的组织方式,所以agent基本是可以复用的,Nightingale中的agent叫collector,融合了原来Open-Falcon的agent和falcon-log-agent的逻辑,各种监控插件也都是可以复用的
> 数据流向和整体处理逻辑是类似的,仍然使用灵活的推模型,分为数据存储和告警判断两条链路,下一节我们基于架构图详细展开

四、调研

4.1、是否能否满足我们的需求

cpu mem 网络 安全审计 采集器是否可扩展
nightingale ? ? ? ? ?
open falcon ? ? ? ? ?

4.2、部署难度

两者之间的部署难度相近

nightingale 都是用go编写需额外用到 redis mysql 和nginx代理
open-falcon 后台使用go编写,前端使用python ,需额外redis 和 mysql
后端程序两者都可以一键启动多个组件

nightingale 节点的部署 略复杂于 open-falcon

4.3、各组件资源占用(初期)

nightingale :( 虚拟机 centos 1cpu 2G)
cpu     mem      module
0.2     1.1     /home/go-www/src/github.com/didi/nightingale/n9e-monapi
0.3     1.0     /home/go-www/src/github.com/didi/nightingale/n9e-transfer
0.0     0.8     /home/go-www/src/github.com/didi/nightingale/n9e-tsdb
0.0     0.8     /home/go-www/src/github.com/didi/nightingale/n9e-index
0.0     0.8     /home/go-www/src/github.com/didi/nightingale/n9e-judge
0.4     4.1     /home/go-www/src/github.com/didi/nightingale/n9e-collector

open-falcon :( 虚拟机 centos 1cpu 2G)
cpu     mem     module
0.0     0.5     /home/work/open-falcon/graph/bin/falcon-graph
0.0     0.5     /home/work/open-falcon/hbs/bin/falcon-hbs
0.0     0.5     /home/work/open-falcon/judge/bin/falcon-judge
0.2     0.4     /home/work/open-falcon/transfer/bin/falcon-transfer
0.0     0.5     /home/work/open-falcon/nodata/bin/falcon-nodata
0.0     0.6     /home/work/open-falcon/aggregator/bin/falcon-aggregator
0.0     0.6     /home/work/open-falcon/agent/bin/falcon-agent
0.2     0.4     /home/work/open-falcon/gateway/bin/falcon-gateway
0.0     0.6     /home/work/open-falcon/api/bin/falcon-api
0.2     0.5     /home/work/open-falcon/alarm/bin/falcon-alarm

4.4、其他对比

# 数据查询
> nightinge 采用TSDB + mysql 存储方式,TSDB 会保存近几个小时的数据,在查询时这段时间内的数据查询会很快,当然也会占用到一定的内存(nightingale原文:tsdb是分片的,tsdb来做缓存的话,只需要缓存自己分片的数据,内存占用较少)
> open falcon 查询数据主要存在在MySQL中,依靠索引查询,速度相对较慢。

# 活跃度对比
> 从github 上的start fork 和contributors 数 nightingale都远少于 open-falcon 
> nightingale 开源时间短 ,但关注度正成迅猛上升趋势,相较于open-falcon 的关注度 2015-2018 这段时间是其高峰

4.5、开发难度

> nightinagle 模块少,流程清晰,易于理解。
> 二次开发的API接口 nightingale 要远远少于 open-falcon, 即nightingale 提供的功能要少于open-falcon,相应的也减少了对其他功能关注
> 百度搜索 open-falcon相关的资料明显多于nightingale。 个人推测在遇到开发难题时,open-falcon可参考的资料较多
> 两个都是采用go语言编写

4.6 结论

个人推荐使用 nightingale,理由如下:
> 查询速度更快,TSDB 保存了近几个小时的数据。
> 内容相对简单,流程清晰。
> 整体上延续了open-falcon,但又做了很多的改进。例如改变了原来gragh的数据存贮方式;将原有的 hbs,alerm,dashboard 组合为一个模块(monapi).
> 开源时间较短,但是发展迅猛
> nightingale 与 open falcon的插件可以复用,api的数量较少, 复杂度不高,开发应较为容易一些
> nightingale 和 open-falcon 都可以满足我们除安全审计外的需求

关于open falcon 与nightingale 的一些调研

标签:体验   趋势   moc   ref   实时   产生   一致性   去除   默认   

原文地址:https://www.cnblogs.com/xiaobaiskill/p/13045313.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有 京ICP备13008772号-2
迷上了代码!