近日，国际互联网运维圈内有着系统工程届“好莱坞”之称的SREcon大会2017年度会议正式举办。了解SREcon的朋友都知道SREcon 是 SRE 领域最专业的大会，由 USENIX 组织，今年的正式名称是 SREcon17 Americas. SREcon 聚集了关注网站可靠性、系统工程、以及复杂分布式系统等领域的技术专家。大会从2014年开始一直在欧美地区主办，而今年则首次登陆亚洲地区。
根据大会主办方显示，大会参与企业均来自互联网领域内顶尖级企业，海外部分(Google，Facebook，Twitter, LinkedIn，Dropbox， Netflix)中国部分(百度、阿里、腾讯、滴滴、小米、华为)等共同参与组成。而大会的分享嘉宾则通过投稿的形式由大会评审团商议决定，本届大会共计收到100多篇来自全球范围内，知名互联网企业的专家投稿。在经过层层筛选后，仅有33篇技术内容得到大会技术团的认可并受邀出席分享嘉宾。就在这33篇嘉宾名单中，光载无限台湾研发中心(以下简称光载无限)首席专家则榜上有名。
据悉，本次光载无限专家分享的内容是，围绕企业级开源分布式监控系统的演进来和参会的各路技术达人们进行了充分的互动。在光载无限专家的介绍中了解到这个台湾研发中心前身由光载无限旗下的北京快网CDN发起组建而成。致力于以开源式监控解决方案基础为蓝本，打造企业自主创新并领先于业内的前沿的分布式监控体系。在接受采访时光载无限专家毫无避讳的表示，我们以open-falcon开源解决方案打造的监控平台，已经在现有CDN网络层中得到了实战的应用。未来一段时间内我们将会推出一块黑科技产品OWL(项目计划)，相信将会更好的服务于企业与客户的共同成长。
未来网络的发展，需要不同领域内更多的技术变革。但谁的技术能踏上这班高速发展的快车的前提，在于你对技术市场发展观的解析。相信正是光载无限专家对于分布式监控的技术发展观以及应用领域的实际落地得到了大会评审图高度的认可。
以下内容为大会分享实录精选
光载无限技术专家：
今天主要分五个部份跟大家介绍Open-Falcon，首先介绍我们Open-Falcon 的项目缘起，接着介绍我们的主要特色。然后从系统架构层面跟大家讲解我们什么样的设计让Open-Falcon 成为具有这些特性.
再来跟大家做海外最热门的开源监控系统Prometheus 的比较，同时让大家了解一下我们目前的生态系。
Open-Falcon 有六大特性，接下来逐一为大家讲解。
可扩展性监控系统是否可以随着业务规模成长而伸缩的重要特性，这也是我们自研监控系统最主要的理由，务必得做好，才能支撑业务的快速成长。也因为这个诉求，所以在Open-Falcon 中我们每个模块都可以轻松地水平扩展。因为水平扩展的关系，Open-Falcon 一个周期中(默认为一分钟)可支援上亿个查询、告警判定、储存、搜索。
提高数据查询速度以及图表渲染速度对于运维巡检的效率会有很大的提升，Open-Falcon 透过RRA (Round Robin Archive)归档机制，一百个监控项一整年的监控数据可以在一秒内返回结果。由于归档机制，节省了硬盘资源的使用，Open-Falcon 可以轻松地存储历史资料超过十年以上。
我们秉持着分布式系统的设计哲学来设计 Open-Falcon，监控是超一级服务，所有的系统都可以下线，监控系统不行。一旦监控系统下线的话，我们就像是瞎子一样，不知道哪里出了问题。所以我们不允许系统有严重的单点故障，系统中多数的模块都是无状态的。宕机的话就是无脑重启就好，在操作以及部署上面的工作相当简单。
Falcon-Agent 内置监控项就已经有四百多个服务器指标，使用者还可以透过插件或是简单运行程式再透过Falcon-Agent 转发的方式来自定义监控项。因为是分布式系统，加上模块都是按照微服务的精神来设计，系统有极佳的扩展性，可以灵活的按照公司内部需求定制化自己的监控系统。
为了简化告警策略的管理，Open-Falcon 支援策略模板、集成以及多个策略制定，还有回调函数用以自动恢复告警。除此之外，为了最佳化工作效率，我们所有的监控项上报的 Endpoint 以及 Counter 都可以被自动发现的，少了很多配置工作。
接下来，向大家介绍一下Open-Falcon 的系统，让大家能清楚的了解我们为什么可以具有这些特性，投影片上面的流程图从左到右表示的是一个监控项的生命周期，底下的字代表的是元件名称。红色是核心功能元件。从这张图可以看得出来Open-Falcon 采用的就是Stream Processing 来处理监控数据。监控项从采集，存储，到告的流程中，都是单向资料流的，这种设计的好处是简单高效;坏处则是牺牲了一定的灵活性。
Open-Falcon 架构，为什么这个架构能够提供我们以上六点特性呢?首先先从最初的设计开始吧。在Open-Falcon 中有九大模块，先从数据采集与上报开始，安装在目标机器上的Falcon-Agent可以采集内建的监控项指标，并且透过Proxy gateway 代理上报或是自己直接上报给Transfer。在某些情况下(如：交换机、应用程序中的性能指标)，Falcon-Agent 是无法安装的，那么我们就需要透过Client Library 或是SNMP 的方式将数据上报到我们的Proxy gateway，这也会是一台agent，但它不一定是在本机上面，也就是说一台设备中所安装的Falcon-Agent 可能上报除了这台设备以外的监控指标。采集后的数据都会上报到Transfer，大家可以用Queue 来理解Transfer，Transfer 会不断地消化清空监控项队列，同时透过一致性哈希的算法发送给Judge 与Graph 模块，需要特别提醒的是两个模块可能分散在不同设备上部署。监控数据到了Judge 之后可以作为告警判定，如果没有满足任何条件的话，就丢弃这份数据了。若满足，则透过Alarm 模块通知相应的用户组。到了Graph 则是永久的储存下来，背后的数据库是RRDTool，并且按照RRA 策略?来做归档。Query 作为一个API 模块，当Dashboard 有画图需求的时候就可以调用Query 的API 来取用数据。还没有提到的是Portal 以及Aggregator，Portal 是Open-Falcon 的配置中心，包含监控策略以及模板绑定都是在Portal 中进行操作。这些数据的关联性我们都记录在MySQL 中，并且透过HBS 与所有的Falcon-Agent 保持心跳定期的下发监控策略已经模板绑定关系。以上的流程讲的都还是Streaming Processing 只能针对单台设备的监控指标储存监控数据、进行告警判定。只利用RRDTool 的数据库不透过其他数据库要做到集群监控确实有点局限，Aggregator 的目的就是为了满足我们对集群监控的需求。Aggregator 会按照我们欲监控的集群配置从Graph 拉取数据，做了相应的计算聚合之后，将它作为一个监控项重新打到Transfer 去，这种简单的设计就满足了我们对集群监控的需求。
所有组件我们都是透过 Center Status 来同步系统的状态，Center Status 主要有两个数据库组成，分别是 Redis 与 MySQL。
在过去 v0.1 版本中，我们的模块很多，图上写的就是我们 Open-Falcon 模块的名称，右下角的数字表示的是在 Open-Falcon 系统集群中部署的实例数量，红色的是最关键的模块：Transfer 作为传输队列，负责收集 Agent 采集上来的数据并且发送给 Graph 以及 Judge，所以负担最大。
因此在 v0.2 版本中，我们进一步的整合模块让系统简化，最终系统可以被分为四大部份：
1. 前端： 第一部份是 Dashboard，Dashboard 是 Open-Falcon 的前端模块，包含所有告警规则、用户、与设备的管理。
2. 后端模块：第二部份是 Falcon-Plus，Falcon-Plus 是 Open-Falcon 的后端模块，它整合了所有 v0.1 中的模块，我们可以使用 Driver 程序来驱动选定的模块并且保留 v0.1 的优良传统。
3. 中心状态：第三部份是 Central Status，Central Status 在前面已经介绍过了，我们这里就不赘述。
4. 数据采集：最后一部份是 Falcon-Agent。
这样的简化改进后不但没有牺牲过去模块化的弹性，还让我们凝聚了社区的开发力量。除此之外，Open-Falcon 可以轻易地结合社区优秀的开源项目，像是 InfluxDB, OpenTSDB, 和Grafana。
前面已经介绍了Open-Falcon 与OpenTSDB 还有InfluxDB 不同的设计理念，也比较了彼此的优缺点，所以在此就忽略不提了。Prometheus 作为海外最热门的开源监控系统，确实成功的吸引了我们的眼球。相信大家也会对这个比较感兴趣。相比于Prometheus，Open-Falcon 的优点是什?么呢?
1. 更丰富的API：我们的目标是希望让Open-Falcon 形成一个业界的监控标准，既然要形成标准就需要简单且完善的API 来提供支持。在API 的支援，开发者完全可以自己设计自己的Dashboard 基于我们后端的Falcon-Plus 就可以设计自己的监控系统。
2. 配置成本低：采用了Push Model 让系统有自发现的能力，这简化了很多配置工作。即便?是大规模集群，我们也可以透过简单的tag 机制让服务器自动归属于对应的HostGroup 之中。支持多种数据展示接口。
3. 可以监控大规模的设备：在小米内部已经跑了三年多的 Open-Falcon 就是最好的铁证，在中国被各大互联网公司大规模采用也证明了 Open-Falcon 极佳的伸缩性。
4. 自有的Dashboard：Open-Falcon API 是针对整个系统设计的，基于这个API 我们开发了自己的Dashboard，相较来说Prometheus 如果数据在不同的节点上就只能把其他Prometheus 配置为数据源然后展示在不同的Dashboard。Open-Falcon 有自己的Dashboard 组件，接合LDAP可以做一些简单的团队和人员管理，另外就是组合多个Endpoint 和Metrics。这些是Prometheus 没有直接支持的，需要自己开发Dashboard。不过因为在告警的策略管理上面 Prometheus Alertmanager 还是具有较高的弹性，例如：聚合、去重、以及静音等等功能。这部份 Prometheus 胜出。
5. 画图效率高：相较于 Prometheus 的 Recording rules，RRDTool 提供的 RRA 归档机制能在更短的时间内返回绘图数据。 Faster query performance of RRA compared to Recordingrules. Metric Type: Summary, Histogram
6. 使用与开发的门槛低：与Prometheus 的Collector/Exporter 相比，我们只保证Agent 收到的客制化监控项，是符合Open-Falcon 格式规范的使用者可以用自己熟悉的编程语言写程序或是脚本来开发客制化监控项。开发插件的门槛较低。
7. 有限的表达式：Prometheus 的最大优点在于它有很灵活的查询语言： PromQL ;使用 PullModel 的设计让它在告警的判定与策略的管理更具有弹性，支持很多组合加工数据的方式;除此之外，Prometheus 在监控项的数据型别也额外支持了Summary , Histogram，图标的展现方式也更多元。这是prometheus最大的亮点。 PromQL 语言还用于存储前的Recording Rule 和报警配置的 Alert Rule。相较之下， Open-Falcon 支持有限的组合方式，比如 SUM, AVG, MAX 等等取样方式。这部份 Prometheus 胜出。
