Open-Falcon存在的问题，重写一套？

一转眼，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多万数据。

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

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

附：