×

Open-Falcon存在的问题,重写一套?

96
秦晓辉
2015.12.31 09:46* 字数 1232

一转眼,Falcon在小米已经跑了一年了,看着自己的孩子一点点长大、成熟,也是一件蛮开心的事情。Open-Falcon开源之后,受到了很多业界同仁的关注,深感欣慰。

过程中,也暴露出了一些问题,今天我们来细数一下Open-Falcon的缺点,对各位做方案选型提供一些帮助。

*系统不易分发

Open-Falcon是从内部版本衍生的,去掉了对小米内部其他系统的依赖,本身组件还是比较多,部分组件使用Python开发,给软件分发造成不小的麻烦,如果对整个架构不熟悉,不知如何troubleshooting,安装过程很难一帆风顺。

*安全性考虑不到位

Dashboard、AlarmDash不用登陆直接就可以查看数据,如果被扫描,还有可能被写入脏数据,被删除数据。Falcon在小米内部因为有网络隔离,外网访问不了,但是一些稍小的公司,直接将Dashboard、AlarmDash放在公网上,就麻烦了

*没有通盘考虑的权限设计

所有的操作理应都有相应权限控制,API的调用也应有相应控制,现在做得还是比较乱,比较弱

*策略表达式易用性不够

现在的策略表达式中只能配置一条规则,此处应该支持配置多条,任何一条触发,就要发报警,不同规则之间应该支持覆盖

*复杂度稍高

对于产品线dev,可能只是想push一些业务监控项,做一些简单的报警配置,把机器分组、策略模板、模板继承等概念暴露给这部分人,增加了他们的理解成本

*每个Graph实例均是单点

这点其实在很大程度上已经算是解决了,Transfer中可以配置Graph双写,虽然手工维护Graph双写列表麻烦了点,好在这个列表基本不怎么变,也可以接受吧

*Graph扩容有损

现在社区的版本,Graph扩容是通过设置migrating标识,新旧集群同时写一段时间,比如一个月,然后去掉老集群,只使用新集群提供服务,一致性哈希的分片策略,会让部分数据发生迁移,这部分发生了迁移的监控项,就只有migrating这段时间的历史数据了。这点我们内部已经在着手解决,敬请期待。

*上下游组件没有naming

Transfer中配置的Graph列表、Judge列表,Query中配置的Graph列表,都是直接写到配置文件中的,缺少一个动态机制,管理起来不方便

*报警没有入库

当前未恢复的报警是存在Alarm内存中的,重启就丢了,历史报警没有入库,无法追溯

*报警现场没有保存

因为使用rrd存储历史数据,一天以后的数据被做了归档处理,查看历史报警时刻的趋势图,无法查看当时的准确值

哇,这么多缺点,我还敢不敢用啊……其实问题没有想得那么大啦,翻阅之前介绍Open-Falcon的文章,你就可以看到很多Open-Falcon的优点啦。小米使用这套系统抗住了每个周期8000多万数据。

一个软件没有经历过几次重写,代码很难变得漂亮,那,笔者现在就在纠结,是否花业余时间重写一套,尝试解决上面提到的这些问题,至少应该做到:

  • 减少组件数量,全部使用Go编写
  • 改进安全性,看图、未恢复的报警均须登录方可访问
  • 增加API访问权限,设计统一的第三方系统调用控制
  • 增强易用性,增强策略表达式功能
  • 保留报警现场
  • 改进历史数据的存储,去除单点
  • 报警事件处理引入类似MQ机制,方便接入其他的报警事件处理模块
  • 简化配置,上下游实例列表动态化
  • 改进索引建立机制,加快索引建立速度
  • 无用的历史数据增加删除机制

嗯,暂时想到这么多,支持笔者做这个事情么?用打赏表明你的态度,(__) 嘻嘻……

附:

DevOps
Web note ad 1