1. 参考资料
   详解十三款运维监控工具 (2017年08月17日)
   开源IT监控系统对比 (2014年9月15日)
2. 选择结果-- open-falcon
   理由
   国内开源(小米)
   文档完整
   插件扩展
   开源背景决定其更考虑互联网特殊需求
   自定义push/插件
   足够开放
   基本介绍
   falcon /'fælkən/, 猎鹰/隼
   open-falcon.org
   github
   book.open-falcon
   特性
   强大灵活的数据采集：自动发现，支持falcon-agent、snmp、支持用户主动push、用户自定义插件支持、opentsdb data model like（timestamp、endpoint、metric、key-value tags）
   水平扩展能力：支持每个周期上亿次的数据采集、告警判定、历史数据存储和查询
   高效率的告警策略管理：高效的portal、支持策略模板、模板继承和覆盖、多种告警方式、支持callback调用
   人性化的告警设置：最大告警次数、告警级别、告警恢复通知、告警暂停、不同时段不同阈值、支持维护周期
   高效率的graph组件：单机支撑200万metric的上报、归档、存储（周期为1分钟）
   高效的历史数据query组件：采用rrdtool的数据归档策略，秒级返回上百个metric一年的历史数据
   dashboard：多维度的数据展示，用户自定义Screen
   高可用：整个系统无核心单点，易运维，易部署，可水平扩展
   开发语言： 整个系统的后端，全部golang编写，portal和dashboard使用python编写。
3. Open-falcon 组件
   Agent: 采集服务器负载监控指标, 部署到所有的机器上
   Transfer: 是数据转发服务。它接收agent上报的数据，然后按照哈希规则进行数据分片、并将分片后的数据分别push给graph&judge等组件
   Graph: 是存储绘图数据的组件。graph组件 接收transfer组件推送上来的监控数据，同时处理api组件的查询请求、返回绘图数据
   Api: 提供统一的restAPI操作接口。比如：api组件接收查询请求，根据一致性哈希算法去相应的graph实例查询不同metric的数据，然后汇总拿到的数据，最后统一返回给用户
   HBS(Heartbeat Server): 心跳服务器，公司所有agent都会连到HBS，每分钟发一次心跳请求
   Judge: 用于告警判断，agent将数据push给Transfer，Transfer不但会转发给Graph组件来绘图，还会转发给Judge用于判断是否触发告警
   Alarm: 模块是处理报警event的，judge产生的报警event写入redis，alarm从redis读取处理，并进行不同渠道的发送
   Task: 监控系统的一个必要的辅助模块. 定时任务实现.
   Nodata: 用于检测监控数据的上报异常。nodata和实时报警judge模块协同工作，过程为: 配置了nodata的采集项超时未上报数据，nodata生成一条默认的模拟数据；用户配置相应的报警策略，收到mock数据就产生报警。采集项上报异常检测，作为judge模块的一个必要补充，能够使judge的实时报警功能更加可靠、完善
   Aggregator: 集群聚合模块。聚合某集群下的所有机器的某个指标的值，提供一种集群视角的监控体验
   Agent-updater: 每台机器都要部署falcon-agent，如果公司机器量比较少，用pssh、ansible、fabric之类的工具手工安装问题也不大。但是公司机器量多了之后，手工安装、升级、回滚falcon-agent将成为噩梦
4. 部署演进
   Open-Falon的部署情况，会随着机器量(监控对象)的增加而逐渐演进，描述如下，

初始阶段，机器量很小(<100量级)。几乎无高可用的考虑，所有子服务可以混合部署在1台服务器上。此时，1台中高配的服务器就能满足性能要求。

机器量增加，到500量级。graph可能是第一个扛不住的，拿出来单独部署；接着judge也扛不住了，拿出来单独部署；transfer居然扛不住了，拿出来吧。这是系统的三个大件，把它们拆出来后devops可以安心一段时间了。

机器数量再增加，到1K量级。graph、judge、transfer单实例扛不住了，于是开始考虑增加到2+个实例、并考虑混合部署。开始有明确的高可用要求？除了alarm，都能搞成2+个实例的高可用结构。再往后，机器继续不停的增加，性能问题频现。好吧，见招拆招，Open-Falcon支持水平扩展、表示毫无压力。

机器量达到了10K量级，这正是我们现在的情况。系统已经有3000+万个采集项。transfer部署了20个实例，graph部署了20个实例，judge扩到了60个实例(三大件混合部署在20台高配服务器上,judge单机多实例)。query有5个实例、平时很闲；hbs也有5个实例、很闲的样子；dashborad、portal、uic都有2个实例；alarm、sender、links仍然是bug般的单实例部署(这几个子服务部署在10左右台低配服务器上，资源消耗很小)。graph的db已经和portal、uic的db实例分开了，因为graph的索引已经达到了5000万量级、混用会危及到其他子系统。redis仍然是共享、单实例。这是我们的使用方式，有不合理的地方、正在持续改进。

机器上100K量级了。不好意思、木有经历过。目测graph索引、hbs将成为系统较为头疼的地方，Open-Falcon的系统运维可能需要1个劳动力来完成。