open-falcon 的新版本特性

open-falcon 0.1 版本发布的时候有人问laiwei下一版大概什么时候发布,他想了想说,“大约是冬季”,所以说open-falcon重新定义了冬季。

废话不多说,先看一下open-falcon新版本有哪些新特性:

这次版本还有一个比较有意思的特性,就是平滑升级,从0.1到0.2几乎可以做到不停服务或者5分钟之类就能完成升级,不过这也从另外一个方面说明这次升级的主要内容不是在核心架构上,重点是在整合上。

滴滴基于open-falcon的监控实践

滴滴在这次发布会中对open-falcon改动最大的一家公司,也因为他们的的改动引发的这次发布会上最大的一个争论焦点, 数据究竟是推好,还是拉好?
首先看下他们的系统架构:
dd----
可以看出,除了一些模块名外,整体的系统架构都改过了, 从系统层次,他们把数据流分成数据流和配置流,通过系统架构图就可以看出,他们可以很轻易的通过config模块实现统一的配置管理。

他们的主要改进有9点:

  1. 监控数据按服务单元分类

  2. 增加垃圾数据清洗

  3. 分级索引

  4. 精简RRA

  5. 巡检大盘支持同环比

  6. 重组看图首页

  7. 报警数据获取由推变拉

  8. 干掉报警模板

  9. 重新定义nodata

  10. 监控数据按服务单元分类:
    这个的实现主要是在agent的数据中增加了服务单元的项:服元务单元 su=${cluster}.${usn}
    这样可以按照服务树查看数据,可以按照服务去查看监控数据。

  11. 增加垃圾数据清洗
    主要是因为agent中会有很多不需要的垃圾数据,如一些trace数据,这样可以减轻监控服务器的压力。

  12. 分级索引
    首先增加了索引模块index,主要是为了加速查询速度。
    dd--

  13. 精简RRA
    由于open-falcon默认归档的历史数据分为最大值,最小值和平均值, 由于存储压力,他们去掉了最大最小值的归档

  14. 巡检大盘支持同环比
    这个主要是界面的改变,还有报警配置中增加的相关报警项。
    dd---

  15. 重组看图首页
    这个主要是根据之前的按照服务单元查看数据做出的在UI上的改动, 看图顺序变成: 服务单元 -> 节点 -> 机器 -> 指标分组 -> 看图 -> 订阅大盘

  16. 报警数据获取由推变拉
    这个就是本发布会问的最多的一个问题了:
    dd------
    open-falcon社区版的框架是transfer会把数据推给judge,然后judge中缓存10个左右历史数据,根据这些数据进行判断是否有报警产生, 所以引起两个问题,第一,无法配置很多报警内容,如多指标,同环比等报警内容; 第二,浪费性能和内存,在正常情况下不管用户是否配置报警,都会把数据push到judge,juge的内存消耗和网络消耗比较大。 如果改成拉的话, transfer不会主动push数据到judge, 改成judge根据自己的需要去拉数据,这样既节约了系统资源,也可以有很多其他重要的功能。
    关于推拉问题,社区也是比较重视,这个改动已经被列入到0.3版本的开发计划里面,就是说到0.3版本,社区版的open-falcon也可以配置很多复杂的报警功能了。

  17. 干掉报警模板
    dd-------1

  18. 重新定义nodata
    重新定义业务场景,正常上报的数据突然中断了, 才需要nodata报警,从来没上报过的数据, 没有必要nodata报警
    nodata--

    至此,滴滴对open-falcon的主要改动就已经介绍完了,可以看出,dd对open-falcon的改动是比较大的,也是比较颠覆式的,可以说它抓住了open-falcon中的几个比较重要的缺陷。

美团

美团对open-falcon改动主要是增强了open-falcon的4个方面:可用性,可扩展性,成本优化还有易用性。
  1. 可用性
    这个主要体现在高可用性上,主要提出了4点:跨机房容灾方案,Judge高可用方案,Alarm高可用方案,自监控方案
    首先看一下跨机房容灾
    mt-----
    这个主要是体现在部署方式上的一个方案
    judge高可用
    mtjudge---
    他们主要的方案是增加了judge的冷备,当judge节点出现问题时,可以让judge冷备顶上。
    alarm高可用
    mt------
    自监控方案
    mt-------1
    通过增加自监控服务去检查每个服务的状态。

    美团在高可用性的方面还是比较上心的, 休息期间我问过他们的演讲人殷大闪,关于graph的高可用问题,他的解锁是当graph节点出现问题时,不会影响报警,而graph中的历史数据可用容忍适当的数据丢失。

  2. 可扩展性
    索引存储改造,过期索引自动删除和重建,手动维护;指定监控项存入OpenTSDB;告警升级、ACK、禁用、发散、合并、自动处理;Ping监控、字符串监控、多条件监控
    其中的多条件监控其实就是一个报警里面可用配置多个报警条件。

  3. 成本优化
    HBS内存优化,Judge内存优化,消耗带宽的优化,告警统计
    其中judge的内存优化其实也就是改进了原来judge中的一些缺陷,原理judge中不管是否有报警项,这些监控值都会在judge的内存中存在一个副本,他们的改进就是只有报警设置时才会缓存这些值。

  4. 易用性
    一键创建Screen且支持Screen收藏夹功能;解决查询历史数据时最新的数据点丢失的问题;支持图表单图刷新并显示数据聚合粒度和采样方法;Tag反选
    rrd-------