[转] open-falcon编写的整个脑洞历程

[From] https://mp.weixin.qq.com/s?__biz=MjM5OTcxMzE0MQ==&mid=400225178&idx=1&sn=c98609a9b66f84549e41cd421b4df74d

讲师：秦晓辉

个人介绍：

一个来自运维部的研发，长期从事自动化运维平台的构建，参与百度自动化部署系统Archer、小米的监控系统open-falcon，偶尔做做PaaS，国内首个开源PaaS平台（噱头，哈）DINP的作者。代码熟手，工程师，not程序员。

分享的主题：《open-falcon编写的整个脑洞历程》

1. zabbix时代的痛

2. open-falcon的目标制定

3. 架构设计的习惯性

4. 试用之后

5. 一些折中

6. 未来改进

大家好，我是秦晓辉，来自小米运维部，毕业这几年一直做运维平台开发，对部署系统、监控系统相对熟悉一些，这次主要是给大家介绍一下open-falcon开发过程中的一些思考，力求以最直白的表述重走一下开发过程，如果你们公司也要写一套监控，或许会有一点帮助，群里大牛众多，献丑了。

本来想提纲挈领的讲一讲，顶多40分钟搞定，写稿件的时候越写越多，限于个人表达能力的问题，而又想尽量讲清楚，总是啰啰嗦嗦的，最后发现时间关系还是没法全部讲到，大家见谅。

我们先来讲讲zabbix时代的痛，小米初期是使用zabbix来做监控的。zabbix大家应该是知道的，大名鼎鼎，成熟稳健，很多公司都在用。小米也不例外，初期做运维开发的人比较少，机器量、业务量也少，zabbix可以很好的满足需求。

我们要开发一个项目、产品，肯定是要解决一些问题，zabbix是很好，但是机器量、业务量上来之后，zabbix就有些力不从心了。那我们先来说一下zabbix存在的问题。

小米在大规模使用zabbix的年代，我当时在研究CloudFoundry，直到众位sre受不了zabbix了，希望开发一个新的监控系统，我们开始组建监控团队，开始open-falcon的设计、编码。所以对zabbix的问题可能理解不深入，抛砖引玉……

1. 性能瓶颈。zabbix是使用MySQL来存放监控历史数据的。一台机器假设有100个监控项，2000台机器，就是20w监控项，监控系统的数据采集没有高峰低谷，是持续性的，周期性的，一般是一分钟采集一次。

机器量越来越大，数据量就越来越大，MySQL的写入逐渐成为瓶颈，业界有一些proxy的方案，我们有试用，也尝试把采集周期调长，比如3分钟采集一次，或者5分钟采集一次，但是都治标不治本。

zabbix有些数据采集是通过pull的方式，也就是server端主动探测的方式，当目标机器量大了之后，这些pull任务也经常出现积压。维护zabbix的同学焦头烂额。

2. 管理成本高昂。为了让zabbix压力小一点，我们整个公司搭建了多套zabbix，比如多看自己用一套、电商自己用一套、米聊自己用一套，如果要做一些公司级别的统计，需要去多个数据源拉取数据。每套zabbix都得有运维人员跟进，人力成本上升。

3. zabbix有些易用性问题。比如zabbix的模板是不支持继承的，机器分组也是扁平化的，监控策略不容易复用。zabbix要采集哪些数据，是需要在server端做手工配置的，我们认为这是一个本该省去的操作。

4. 监控系统没有统一化。机器相关的数据采集、监控我们使用zabbix来做，但是我们还需要业务的监控，比如某个thrift rpc接口，每分钟调用的cps，latency，我们希望做监控，某些url的5xx、4xx我们也希望做监控，某个开源软件，比如redis、openstack、mysql的一些状态统计数据，我们也希望做监控。

我们称后面这些数据为performance数据，我同事来炜曾经专门写了一个系统叫perfcounter，用来存放这些performance数据。perfcounter使用rrdtool来绘图，rrd是一个环形数据库，很多监控系统的数据都是使用rrd来存储的，这个就不展开讲了，大家可以google一下rrd相关知识。

perfcounter的绘图做得不错，但是报警功能比较薄弱。zabbix本身有多套，再加上perfcounter，入口比较多，要看监控数据，可能要去不同的地方分别查看，比较麻烦。迫切需要一个大一统的解决方案。

不可否认，zabbix是个很优秀的方案，初期zabbix帮我们解决了很大的问题，不过如上所述，我们在使用过程中也遇到了一些问题，刚开始的时候提到过，zabbix时代我还在做PaaS，所以上面的说法主要是在做open-falcon设计的时候从各位sre了解到的。

下面我们来说说open-falcon的目标制定。我们已经确定要做一个新的监控解决方案了。于是开始讨论，这货应该做成什么样子。每个人可能都会有一些思考，但是每个point基本都比较散乱，我初入监控这个业务，主要是推动大家的讨论，然后整理方案，再讨论，再整理，最终出一个产品需求文档和概要设计。

有人说，我们应该既可以处理机器监控，也可以处理业务监控，还可以处理各种开源软件的监控。

没错，就是要这种大一统，而且不同的系统有不同的采集方式，有不同的监控指标，DBA对MySQL熟悉，知道应该采集哪些指标，云存储团队对HBase熟悉，知道应该采集哪些指标，但是我作为监控系统的开发人员，我对MySQL不熟，对HBase不熟，所以我们无法提供其对应的采集脚本。

下面重点！

所以我们要制定规范，制定推送接口，大家自己去采集自己的系统，完事按照我们的规范，把数据组织成监控系统需要的数据格式，发送给监控系统的接口。这样大家就可以共建监控数据，把各种需要监控的软件、平台都纳入进来。

当然了，对于操作系统的一些指标，比如cpu、内存、IO、网卡、磁盘、负载等等，这个还是需要我们监控系统开发人员去提供采集机制的。

于是，我们仿照zabbix_agentd，编写了falcon-agent。

这一部分主要是讲监控系统的数据采集机制

这里有哪些思考的点呢？首先，我们不希望用户在server端配置哪个机器应该采集哪个指标，这样做麻烦且没必要。我们尽量把agent做得可以自发现，比如某机器有12块盘，agent应该可以自动探测到，然后采集各块盘的指标push给server；比如某个机器有2块网卡，agent也应该自动探测到，把各块网卡的流量、丢包率等信息采集push给server。

就是说，我们希望在装机的时候就把agent安装好，agent就可以自动去采集相关数据了，省去了服务端的配置。

顺着这个思路继续延伸一下哈，天不遂人愿，我们希望服务端不做任何配置，agent就可以自动去采集，这是我们的设计哲学，但是有的时候还是要打破一下，比如端口存活监控、进程数监控。

我们拿端口存活监控来举例，按照我们自动去采集数据的哲学，agent应该如何处理端口存活性呢？大家稍微思考一下。

刚开始我们的想法是这样的：我们可以把当前机器上监听的所有tcp端口收集到，汇报给server，比如某机器监听了22、80两个端口，ss -tln，获取之。这样的确是可以收集到数据。但是我现在要做80端口的存活性监控，server端应该怎么做呢？

想想cpu.idle，我们通常会在server端做配置，说某个机器的cpu.idle，连续3次<5%，就报警，最多报3次。这个策略要想正常工作，cpu.idle的数据就应该源源不断的上来。每个周期都不能少。

但是端口监控，ss -tln，可以获取当前有哪些tcp端口在监听，假设现在nginx进程挂了，80端口不再监听，ss -tln就只能获取到22端口，获取不到80端口了，于是汇报给server端的数据就少了80端口的数据。

类似cpu.idle的监控方式是需要数据源源不断上来的，于是，端口监控在这种模式下无法完成。怎么办？

我们可以写一个nodata的组件，来判断数据多长时间没上来就报警。但是nodata组件实现起来还有点小麻烦，而且还存在另外两个问题，一个是策略配置方式与cpu.idle等数据的策略配置方式不一样，比如cpu.idle是all(#3)<5报警，端口存活需要配置成类似：nodata(300)，方式不同用户的使用成本会上升；再一点是有些机器可能监听了N多个端口，但是真正需要监控的端口，只有少量几个，自发现端口造成资源浪费。

all(#3) 表示连续3次都

nodata(300) 表示300s没数据上来

换个方式……

端口不再做成自发现的。用户要想对端口做监控，最后肯定是要配置策略的。我们从用户配置的策略中找出所有需要监控的端口，通过hbs模块下发给agent，这样agent就可以只对特定端口做监控了。比如刚才的例子，某主机需要监控22和80两个端口，用户必然在服务端配置策略，我们从策略中分析出22和80，然后下发给对应的agent，agent就可以只监控这俩端口了，端口活着，汇报个1给服务端，端口死了，汇报个0给服务端，比如:net.port.listen/port=22 value=1，net.port.li1，net.port.li1，net.port.listen/port=80 value=0

下发这个动作是通过hbs这个模块来完成的，即heartbeat server。agent每分钟去调用hbs，询问自己应该监听哪些端口、哪些进程、要执行哪些插件。通过这种机制来下发一些状态信息。

OK，数据采集这部分，就是这么多内容：

1. server端制定接口规范，以此接入各种监控数据

2. agent自发现采集各种Linux性能指标，无需server端做配置

3. 进程、端口监控等无法做到自发现的，又不想引入nodata组件，想让策略配置统一化，就需要hbs来下发信息。

继续下个点之前，这里再补充两点不太重要的。

1. agent要采用什么语言来开发？

开发open-falcon这个系统之前，其实我最熟悉的语言是java。但是agent要run在所有目标机器上的，用自己最熟悉的java来开发么？要run agent，每个机器上都要先启动一个java虚拟机，这有点扯……

我们希望找一个资源占用尽量少的语言，C、C++或许是个不错的选择，但是C、C++我并不熟悉，据说写不好还容易内存泄露，呵呵。C/C++相对更底层，对于不同的操作系统可能要写很多分支，简单看过zabbix_agentd的源码，各种操作系统的分支处理，很麻烦。当然了，zabbix希望兼容各种操作系统，所以写的分支比较多，我们公司的操作系统清一色centos，不会有这么多分支判断。

我们希望找一个更工程化的语言，不容易出错的语言，毕竟要在所有的机器上部署，今天这个core了明天那个core了也让人受不了。

go语言看着还不错哦。首先，go是静态编译的，编译完了一个二进制，扔到相同平台的机器上可以直接跑，不需要安装乱七八糟的lib库，这点特别吸引我，特别是我在上家公司做过相当长一段时间的自动化部署，这种部署友好的静态编译发布，我喜欢。

go的进程不需要java那种虚拟机，资源占用比较少；go的并发支持是语言层面的，server端需要并发的组件用着合适；go的资源回收是defer关键字，也不是传统的try...catch...finally，干净且不容易出错；go的function可以有多个返回值，错误处理通常是一个额外的error类型的返回值，无需抛异常，因为是返回值，不刻意忽略的话就肯定会记得处理，否则编译都过不了；go与github结合，生态建立的比较快；go的模板看起来怪怪的，还好我不需要用……

2. agent怎么扩展？

我们可以在agent中预置一些采集项，但是我们不是神，无法覆盖所有的需求。有些用户需要扩展agent的功能，采集更多的指标。我们需要提供这种机制。这就是插件机制的设计初衷。

zabbix是有一个目录，大家只要把采集脚本放到这个目录，zabbix就去执行。这样做自然是可以解决问题，但是有些问题其实是扔给了使用者，比如脚本的分发管理问题。

那我们来思考，要采集数据发送给server端，应该要做哪些事情呢？

a) 写一个采集数据的脚本

b) 把脚本分发到需要采集数据的机器上

c) 写一个cron每隔一段时间去跑这个脚本

d) 收集脚本的输出，调用server的接口去push数据

e) 根据需求相应的对脚本做上线、下线、升级

插件机制是如何解决这几个过程的呢？首先，脚本肯定还是要用户自己写，但是我们提供一个脚本的管理，采集脚本是代码，代码就需要版本管理，我们内部有个gitlab，要求用户把插件提交到我们指定的git repo。然后agent每隔一段时间去git pull这个git repo，采集脚本就完成了分发。

然后我们在server端提供一个配置，哪些机器应该执行哪些插件，通过hbs把这个信息分发给agent，agent就可以去执行了，脚本按照一个什么周期去跑呢？这个信息写在脚本的名称里，比如60_ntpoffset.sh，60表示60s执行一次，agent通过对脚本文件名的分析，可以得知执行周期。

执行周期也可以在server端配置，都可以，我们是放到文件名里了

脚本执行完了，把输出打印到stdout，agent截获之后push给server。插件的升级、回滚，就是通过git repo和server端的配置来完成。

OK，数据采集就说这么多，真的是又臭又长，哈。我们回到系统设计阶段，看还有哪些点值得分享一下。

1. tag的设计。这个要好好跟大伙说说。这个设计灵感来自opentsdb，我们说监控数据有很多，如果对每条监控项都配置报警，是一个很繁重的工作量。那我们能否通过某个手段来对采集项做个聚合，一条配置可以搞定多个监控项？

举个例子，比如某台机器有多个分区:

/

/home

/home/work/data1

/home/work/data2

/home/work/data…

/home/work/data12

我们想配置任何一个分区的磁盘剩余量小于5%就报警，怎么办？上例中，假设我们有12块盘，加上/home分区和/分区，就有14个采集项，写14条策略规则？OMG……

这个时候tag机制就派上用场了，采集到的数据在汇报的时候，每条数据组织成这个样子：

{

"endpoint": "qd-sadev-falcon-graph01.hd",

"metric": "df.bytes.free.percent",

"tags": "fstype=ext4,mount=/home",

"value": 10.2,

"timestamp": 1427204756,

"step": 60,

"counterType": "GAUGE"

}

上面表示qd-sadev-falcon-graph01.hd这个机器的/home分区的磁盘剩余百分比（df.bytes.free.percent）

再举个例子

{

"endpoint": "qd-sadev-falcon-graph01.hd",

"metric": "df.bytes.free.percent",

"tags": "fstype=ext4,mount=/home/work/data1",

"value": 10.2,

"timestamp": 1427204756,

"step": 60,

"counterType": "GAUGE"

}

metric（监控项名称）是相同的，只是tag不同，不同的tag表示不同的挂载点。这样一来，我们就可以这么配置策略：说，对于某一批机器而言，df.bytes.free.percent这个采集项，只要value<5就报警。我们没有配置tag，那么这14个挂载点的数据都与这个策略关联，一个策略配置，搞定了14条数据。还有比如网卡也可以用类似的处理方式。

上面的例子还无法完全体现出tag的威力。我们再举个例子，说一个业务监控的例子。小米的好多服务都是java写的，有个团队依据open-falcon提供的接口规范，写了一个通用jar包，所有thrift中间层服务，只要引入这个jar包，就可以自动采集所有rpc接口的调用延迟，于是，产生了N多这样的数据：

{

"endpoint": "qd-sadev-falcon-judge01.hd",

"metric": "latency",

"tags": "department=sadev,project=falcon,module=judge,method=com.mi.falcon.judge.rpc.send",

"value": 10.2,

"timestamp": 1427204756,

"step": 60,

"counterType": "GAUGE"

}

插一句：业务代码中嵌入监控采集逻辑，目前我们的实践来看，真的很好用，嘿

如果我们这么配置：latency/department=sadev all(#2) > 20就报警。就意味着对sadev这个部门的所有rpc接口的latency都做了策略配置。覆盖了N条监控数据。怎么样？有那么点意思吧？

说白了，tag就是一种聚合手段，可以用更少的配置覆盖更多的监控项。

OK，tag的设计就讲这么多。下面我们说说模板继承。zabbix的host有一个扁平的group来管理，模板是无法继承的，这个让我们的管理非常不方便。举个例子。

sadev这个部门的所有机器可以放到一个group，配置load.1min大于20报警，sadev这个部门下有很多项目，比如falcon这个项目，falcon这个项目整体使用机器资源比较狠，于是配置的load.1min大于30报警，falcon这个项目下有很多模块，比如graph模块，graph的机器负载更重，正常的load.1min都是35，我们希望load.1min大于40报警。于是问题来了

qd-sadev-falcon-graph01.hd这个机器是graph的一台机器，它应该处于graph这个组，自然也应该处于falcon这个组和sadev这个组，于是，这个机器与三个模板都有绑定关系，load.1min>20的时候报一次警，>30 >40的时候都会报警，这显然不是我们需要的。

模板继承可以解决这个问题，graph.template继承自falcon.template，falcon.template又继承自sadev.template，sadev.template中配置各种常用监控项，比如cpu.idle < 5报警，df.bytes.free.percent < 5报警，load.1min < 20报警，falcon.template和graph.template中只是load.1min比较特殊，那就只需要对load.1min配置特定的阈值即可。如此一来，graph的机器只有在load.1min>40的时候报警，>20的时候>30的时候都不会报警，大家理解一下。

模板的思考就讲解到这里。下面说说这个机器分组的问题，open-falcon与zabbix一样，都是使用扁平的分组结构。这种情况有个问题，就是机器的维护不方便，比如上面的例子，我们graph机器要扩容，需要把新扩容的机器加入graph这个组，同时也要加入falcon这个组，加入sadev这个组，比较麻烦。

所以小米内部的实践方式是与内部的机器管理系统相结合，那是一个树状的结构，机器加入graph中，也就自动加入了falcon中，自动加入了sadev中。大家如果要在公司内部引入open-falcon，最好也要做个二次开发，与自己公司的CMDB、服务树、机器管理之类的系统结合一下。

那这里有一个点，好多公司把机器管理、服务树、CMDB这种管理机器的系统做成树状结构，原因何在？部署系统有这个需求么？部署系统的最小部署单位通常是模块，一个模块所在的机器完全可以放到一个扁平的group中。树状结构不是部署系统的需求，而是监控系统的需求，监控系统通常在一个大节点上绑定一些常用的策略配置，然后在小节点上绑定一些特殊的策略配置，相互之间有个继承覆盖关系。好多人不理解这个树状结构的设计初衷，我的理解就是这个样子的，不一定对哈，个人观点而已。

我们继续往下讲：架构设计的习惯性

这个阶段有哪些脑洞历程呢？首先，监控系统的数据量估计是不小，你看一个zabbix都扛不住对吧，哈哈……而且没有高峰低谷，周期性的，每时每刻都有大量数据上来。那第一反应是什么？

没错，上集群！一台机器无论如何都是搞不定的，那就必须要搞多个机器协同工作。

监控系统的本质，在我看来就是采集数据并做处理的一个过程。处理方式最重要的有两种，一个是报警，一个是存储历史数据。这两个处理逻辑差异比较大，报警要求速度很快，尽量在内存里完成；存储历史数据主要是写磁盘，读少写多。

那最直观的思路就是把报警做成一个组件，把数据存储做成另一个组件。先说存储，之前说过，我们内部有个perfcounter系统来存放performance数据，这个系统是用rrd来存放的数据。架构设计的习惯性，让我们再次选择使用rrd来做存储，毕竟rrd是很多监控系统的存储介质，随大流，问题不大。

rrd是本地文件，一台机器的磁盘容量或许可以搞定监控系统的所有数据，但是IO肯定不够，perfcounter当时用了5台机器，全部都是ssd做raid10，IO还是比较高。所以，要搞多台机器来存放rrd文件，每台机器只处理一部分，压力就小了。

于是，我们习惯性的使用perfcounter采用的一致性哈希算法，来对数据做分片。数据分片通常有两种方式，一个是使用算法来计算，一个是在中心端记录一个对应关系。监控系统的量会比较大，如果要使用对应关系，还得维护一个存储，当时我个人其实是主张使用一个存储来存放对应关系的，但是团队其他成员都觉得略麻烦，就放弃了，直接使用一致性哈希来计算对应关系，架构上显得简单不少。

大家应该知道，使用算法来计算对应规则，会有一个比较麻烦的问题，就是扩容，一旦扩容，一些本来打到老机器的数据就会打到新机器上，虽然一致性哈希的算法会使迁移的量比较少，但是仍然不可避免会有数据迁移。这个问题怎么办呢？

分享一个观点：遇到一个比较棘手的技术问题，如果能在业务层面做规避，将是最省事的。于是我们就想业务上能否接受数据迁移时候的丢失呢？说实话，不太容易接受，能不丢，尽量还是不要丢。

于是我们退一步，扩容的时候，我们不是立马迁移到新机器列表，而是先做一段时间的migrating，比如做一个月。这样一来，扩容之后，对于每个监控项还是会有至少一个月的数据，这样用户是可以接受的。

说完了存储，我们再来说说报警。报警数据要求的历史点数比较少，比如我们通常会配置说某个机器的cpu.idle连续三次达到阈值就报警，这里的“连续三次”就意味着，只要有最近三个点就可以搞定用户这个策略。数据量少，但是访问频繁，因为每个数据上来，都有可能找到其关联的策略，都需要拉取其历史点做判断，这样的场景，没啥说的，用内存吧。

我们把用来处理报警的这个模块称为judge，judge会有很多实例，当时想，某个实例挂了或者重启都不应该影响正常的报警，为了能够水平扩展，尽量做得无状态，那历史数据就不能存在judge的内存里了。redis吧，有名的内存nosql。于是我们就一次性上线了一堆judge实例，前面架设lvs做负载均衡，数据使用redis存储，走起。

稍总结一下，对于server的数据处理，这个属于产品实现细节了，我们因为团队人少，刚开始只有俩人，后来三个，所以力求简单，粗暴的解决问题。数据通过一致性哈希对rrd做一个分片，确实可以大幅缩减开发时间，不过也存在一些问题，大家发现问题在哪里了么？

下面我们先说试用之后立马发现的问题。

当时第一版上线，用了7台机器56个redis实例，给judge存放少量历史数据，发现每个redis的qps都是4K、5K的样子，第一版只是部署了少量agent（具体的量记不清了），结果qps就这么大，当时agent比较少，redis的压力让我们不能接受。

怎么办？大家有思路么？

外部内存的速度如果跟不上，那最直观的想法就是使用进程自身的内存，这里也就是judge组件的内存。那如果用了judge的内存，judge就有状态了，就无法水平扩展了呢。

仔细想想其实问题不大，judge使用内存的话，仍然需要使用算法做分片，既然绘图组件用了一致性哈希，那可以复用一下。同一个监控指标的数据，当前这分钟上来的数据打到某个judge，下一分钟上来的数据，同样应该打到这个judge，一致性哈希可以做到，没问题。

每个judge实例只处理一部分数据，比如50w，放到内存里量也不大，只是Go的GC不知道好不好用，如果Go的GC不好用，我们就在单机多搞一些judge实例，做进程级隔离，先想好退路，呵呵。

judge是数据驱动型的。就是说，数据来到我这个实例，我就去处理，数据没来，我就不处理，judge前面有个组件叫transfer来做转发，做一致性哈希计算，可以保证数据分发规则，看起来都没啥问题。最惹人烦的是什么呢？是judge重启，大家可以想想judge重启会带来哪些问题

judge一旦重启，就丢掉了历史数据，比如用户配置说某个机器的cpu.idle连续3次达到阈值就报警。前两次都达到阈值了，然后，然后judge重启，这俩点就丢了。judge重启完成，又上来一个达到阈值的新点，已经满足连续3次达到阈值了，但是，却无法报警。如果后面继续有两个点达到阈值那还好，还是会报警，如果后面的点都正常了，那这次本该有的报警就永远都不会报了。

这个问题业务上可以接受么？好吧，我们又来问业务了。首先，judge重启的几率比较小，只有升级的时候才会重启，代码写得注意一些，理论上是不会挂的；再一点，机器一旦出了问题，如果sre不介入处理，通常采集到的点都是持续性达到阈值，所以总是会报出来的，否则基本就可以不用关心。

这么看来，这个改造是可以进行的。于是，代码开始重构，上线之后效果大大好转，处理能力是原来的8倍左右。

本来想单开一节来说说一些折中考虑，发现折中都穿插在前面讲完了，那我们就不再单独讲系统的折中处理了。

时间已经比较久了，其他一些小的点我们就先不讲了，最后我们说说系统的问题以及未来的改造。

最大的问题是什么？相信大家已经想到了，就是每个graph（绘图组件）实例都是单点。如果某一台绘图机器磁盘坏，那这部分数据就丢了。怎么解决呢？

最简单的，硬件解决，我们每个机器都是ssd做raid10，稳定性比较高。然后，我们做了一个双写机制，但是现在的绘图机器IO已经比较高了，再搞个双写，势必要加机器，老板最近又在搞什么控制成本云云，就算了吧。监控数据虽然不是丢了会死人那么严重，但是如果不解决仍然让我们如鲠在喉。

于是，我们开始求助于一些分布式存储，我们做数据分片，做双写备份，很大程度上其实就是在解决分布式存储领域的问题，那我们为什么不直接使用分布式存储呢？

opentsdb，嗯，看着还不错，就是用来存放时间序列的数据。我们组一个同事聂安对opentsdb做了一些调研，觉得不能满足需求，两点：1. opentsdb不提供归档，要查看一年的历史数据，opentsdb就真的去把一年的所有点load出来，速度慢不说，浏览器非卡死不可； 2. opentsdb有tag数目限制，tag数不能多于8个，但我们在用的过程发现，好多业务数据的tag都是9个10个，没法减少。

大家看rrd的时候顺便看一下它提供的归档机制，很强大

通过改代码，或许可以调整tag数不能多于8个的限制，但性能可能会急剧下降。另外在很早的时候，同事来炜曾简单尝试过opentsdb，当时只用了10来台opentsdb前端，一打就挂一打就挂，可能是我们机器用的太少，也可能是某些参数没有做调优，时间关系，当时没有深入去研究，但是先入为主的觉得opentsdb不够强。再加上聂安这次调研，我们最终就放弃了opentsdb。

小米有好几个hbase的committer，团队强大，我们现在准备直接使用hbase做存储，云存储团队给我们技术支持，自己做归档，用hbase做后端，实现一个分布式rrd。目前基本开发完成，测试中……如果OK的话，以后就不用担心graph单点数据丢失的问题了。

第二个问题：agent挂了无从知晓

这个问题的本质其实是一个nodata的需求，也就是数据多久没上来应该有个报警机制。开源版本的open-falcon目前没有提供解决方案。应该如何设计这个nodata组件呢？

nodata组件的开源工作应该正在进行中

我们还是不希望改变用户的使用习惯，比如现在每个agent每个周期都会push一个agent.alive=1的数据，用户只要在portal上配置说all(#3) agent.alive != 1就报警。如果没有nodata组件，这个策略是没法工作的，因为agent挂了，不会有agent.alive=0的数据上来。那我们只要写一个组件，在发现没有agent.alive数据的时候就自动push一个agent.alive=0的数据不就可以了么。

O了，这就是nodat组件的工作逻辑，我们可以配置一些关键的指标的default值（当server端发现没有对应数据上来的时候，就自动push一个default值），注意，这里只是配置了一些关键指标，不是所有指标都配置，如果所有指标都配置，工作量不可接受，而且也没必要，比如agent会采集cpu、内存、磁盘、io等很多数据，我们没必要为这些数据都配置default值，只要配置agent.alive的default值是0，就可以了，就可以监测到agent是否挂掉。

最后一个问题：如何处理集群监控

比如我们有一个集群，挂一两台机器没啥问题，但是挂的机器超过10%就有问题了。另一个例子：我们有个集群，失败请求率小于5%没有问题，大于5%了就要尽快接入处理了。

这种从集群视角去判断阈值的情形，应该如何支持呢？

这个问题如果从简单着手，可以直接做成：对一批机器的某个指标做一个相加。比如某集群有30台机器，要对集群的整体错误率做一个统计，只要每台机器都计算一个本机的错误率：query_fail_rate=query_fail/query_total，然后把所有机器的这个query_fail_rate相加求平均即可。

但是，这样做显然是不太准确，更准确的做法应该是把所有的query_fail相加，把所有的query_total相加，然后做除法。

所以最后可以抽象为一批机器+一个除法表达式。一批机器就是指某个集群的所有机器，一个除法表达式，在上例中，其分子是query_fail，分母是query_total。集群指标聚合的这个组件姑且称之为aggregator，这个aggregator组件得到机器列表和分子、分母之后，就可以去计算了。把每个机器的query_fail查询到并全部相加，把每个机器的所有query_total查询到并全部相加，最后做个除法即可

这种做法是否可以解决集群机器挂的数量达到某个值就报警的需求？没问题的，分子是agent.alive，分母是机器总量，比如30（这个可以动态计算），agent.alive正常来说都是1，如果挂了就是0（我们的nodata组件的成果），比如有3台挂了，分子之和计算出来应该是27，分母是30，27/30<90%? 符合阈值就报警。

这种抽象看起来问题不大，最后一点要说明的是，aggregator模块去计算的集群聚合结果应该是每个周期都要计算，计算结果要重新push给falcon，这样这个集群的聚合结果就可以像一个普通的监控项一样，可以用来绘图，可以用来报警。

OK，已经挺长时间了，整个open-falcon的脑洞历程就讲解这么多，希望对大家有帮助，谢谢大家。

Q1 和elk或者stasd加graphite比是否使用方便

A1. 这个方便程度很难讲了，falcon侧重的是做一个监控框架，纳入各种数据，然后做好报警，还有历史数据归档，和elk之类的可能目标不是完全一致，不是一类产品

Q2. 最后说的 求 集群监控 query_fail_rate 的部分应该也会有 单点问题的吧、怎么规避的呢

A2. aggregator模块的确是会有单点问题的，目前还没有去解决，可以做个选主之类的逻辑，多个实例一起上，但是每次只有一个主在工作

Q3.我想请教一下，open-falcon将大多数监控处理放到了agent，部署升级得关注版本一致性，如果使用snmp协议监控资源，服务端每次采集资源时通过go的goroutine并发采集入库，资源报警和其他程序通过trap反馈给服务端，感觉是否会更方便一些，问的比较弱，见笑了。

A3. snmp没有agent强大，agent作为一个常驻进程运行在机器上，可以干的事情更多一些，而且snmp去pull，server端的压力会大一些，处理起来略麻烦

Q4.监控在告警时存在误报么、怎么保证每条发送出去的告警都是有用的？

A4. hbs只是用来分发agent要执行的插件、要监控的进程、端口，不做报警相关的处理，这样逻辑结构上更清晰一些:)

Q5. 目前业务层也接入了监控系统，会出现监控系统单点故障导致全局的应用全部不可用吗？

A5. 业务系统中嵌入监控的逻辑，就要很小心了，这个监控逻辑不能阻塞主要业务处理，只是一个旁路，一个单独的线程，监控系统整个挂了，不会影响到各个业务：）

Q6.监控在告警时存在误报么、怎么保证每条发送出去的告警都是有用的？

A6. 误报这个是不存在的，都是按照用户的策略去报警，当然，有的时候用户不知道自己的阈值设置多少合适，随便设置了一个，这种情况报的警可能确实没啥用处

Q7、agent端数据采集点有多少，性能压力是怎样的？

A7. agent在所有目标机器上部署，比如有1w台机器，就要部署1w个agent，每个agent大约采集200各监控项，现在小米的falcon应用情况是每个周期5000w左右的数据上来，有几十台监控server端协同工作

Q8、jduge中的transfer做转发，这个是单点处理么？如果挂了怎么办？

A8. transfer只是一个转发组件，是无状态的，transfer挂个一两台没有问题

Q9、看到agent运行脚本的时候，采集的是stdout的数据，stderr的数据采集么？如果不小心采集了二进制数据，是怎么处理？不小心调试的时候采集数据量比较大，阻塞了网络的情况有么？

A9. 只采集stdout是一种约定，需要汇报的数据写入stdout，脚本运行出错了写入stderr，如果采集的脚本不能decode成要求的数据格式，直接扔掉。目前没有出现调试的时候数据量大阻塞网络的情况：）

Q10、agent是打包到你们的镜像文件中，系统安装完后自动启动，然后上报么？如果是这样，那么什么时候填写的服务器地址？

A10. 我们的系统由系统组统一装机，然后统一初始化，初始化的时候安装一些基础组件，agent就是在这个时机安装，之后各个业务线再做针对自己业务的初始化工作：）

Q11. 有没有相应的监控报表之类的？是否可以对接kibana

A11. 现在基本没有报表性质的东西，只有趋势图，针对各个监控项的历史趋势图。哦，还有一个未恢复的报警列表，各个产品线工程师可以在下班的时候看一眼这个未恢复的报警列表，看是否有忘记处理的。其他就没了，不懂kibana：）

Q12 如此多的监控项和图表如何展示，如何快速找到需要的东西

A12. 一般我们要看什么数据是有很强目的性的，比如某个服务挂了，你可能要看这个服务所在机器的情况，于是就可以拿着机器名之类的去搜索，也可以根据metric（监控项）去搜索，等等。也可以提前做screen，把经常要看的图表放在一个页面

Q13. 是否有监控到异常，然后自动对服务器进行后续操作的？

A13 有的，异常了之后通常的处理是报警，也可以回调一个业务的接口，把相关的参数都传递个这个接口，用户就可以在这个接口中写自己的业务逻辑，比如去重启某个机器