参与开发和维护小米的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对应的资源。

没有告警升级

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

参考