参与开发和维护小米的falcon系统也有挺长时间了，总结一下falcon的一些优点和缺点。如果对falcon不了解，建议先对下这篇文章《open-falcon介绍》

先说下具备的优势：

  • 灵活的数据采集，支持自定义数据上报
  • 支持策略模板、模板继承和覆盖
  • 高效的告警判别，支持告警暂停、维护周期设置
  • 组件支持水平拓展
  • 大部分用golang编写，部署相对简单

说了优点，下面说说缺点以及改进方案

对上报数据没有做限制

当时处于是内部系统的考虑就没有做权限方面的控制，现在发现如果用户操作失误，短时间内推送大量数据，对后端graph会产生很大的压力。所以权限这块要进行加强。 解决方案： 上报指标和告警接收组绑定，每个告警接收组限定一个上报counter数，超出限额的部分不在接收。

策略模板继承和覆盖计算消耗大量资源

目前每个周期judge从hbs获取策略时，所有策略的继承都要从新计算一遍，消耗大量cpu资源。 解决方案： 由全量计算改为触发计算，新建一张表，记录父模板和子模板的对应关系，策略只要一发生改变，就立即找此模板对应的所有子模板，一直遍历下去，直到没有子模板为止，将和此父模板相关的策略全部修改为最新策略，这样下次获取到的策略都是计算好的，直接从数据库读取即可，减少了cpu计算量

nodata容易误报

现在nodate的处理逻辑是这样的，falcon-agent每个周期，会上报一个aagent.alive=1的指标，nodata每个周期会从后端历史数据接口获取最近一个点agent.alive的数据，如果获取不到，则自动上报一个agent.alive=1，这里会有一个问题，如果agent上报有延迟，在nodata查询的时候，数据还没上去，nodata会上报一个agent.alive=0，而后上报的agent.alive=1则会被丢弃，造成误报。 解决方案： 之前nodata的方案需要数据重新从transfer到judge再走一遍。数据链路太长，新的方案直接通过judge组件完成，由judge维护一个上报数据来源的hostname列表，由于judge的每个counter都会保留最近的10点，所以通过hostname+agent.alive能拿到最近的数据点，如果当前时间点减去最近的时间点大于3个周期的时间，则基本可以说明数据已经不再上报了，然后触发一次告警判别，这种方案能很好的解决误报问题。

用户的一些操作权限设置不合理

用户配置的策略只有自己可以修改，screen所有人都可以修改，有同事离职了，想做修改，需要直接操作数据库，这样很不好。 解决方案： 用户在web端的所有操作都和所在的team绑定，同一个team的人可以修改，查看team对应的资源。

没有告警升级

告警触发后，如果没人响应，达到最大报警次数后，有被忽略的风险。如果告警触发后，经过一段时间没有恢复，继续发给另一批人，再次对相关人员进行提醒。 解决方案： 这个还没想到很好的解决方案，欢迎讨论: )

参考