一转眼，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机制，方便接入其他的报警事件处理模块
- 简化配置，上下游实例列表动态化
- 改进索引建立机制，加快索引建立速度
- 无用的历史数据增加删除机制
嗯，暂时想到这么多，支持笔者做这个事情么？用打赏表明你的态度，(__) 嘻嘻……
附：
update：我们终于完成了这个重写的目标，夜莺来了
夜莺英文名字Nightingale
可以称为Open-Falcon的下一代产品，欢迎试用！
