基本情况

起初在 LeanCloud 内部是直接使用了 Open-Falcon 。 后续的使用过程中因为自己的需求做了大量修改，然后开源。

截图

设计思路

Satori 希望最大程度的减少监控系统的部署维护难度。如果在任何的部署、增删维护报警的时候觉得好麻烦，那么这是个 bug。

监控时的需求很多样，Satori 希望做到『让简单的事情简单，让复杂的事情可能』。常用的监控项都会有模板，可以用 Copy & Paste 解决。略复杂的监控需求可以阅读 riemann 的文档，来得知怎么编写复杂的监控规则。

因为 LeanCloud 的机器规模不大，另外再加上现在机器的性能也足够强劲了，所以放弃了 Open-Falcon 中横向扩展目标。如果你的机器数量或者指标数目确实很大，可以将 transfer、 InfluxDB、 riemann 分开部署。这样的结构支撑 5k 左右的节点应该是没问题的。

在考察了原有的 Open-Falcon 的架构后，发现实质上高可用只有 transfer 实现了，graph、judge 任何一个实例挂掉都会影响可用性。对于 graph，如果一个实例挂掉的话，还必须要将那个节点恢复，不能通过新加节点改配置的方式来恢复；judge 尽管可以起新节点，但是还是要依赖外部的工具来实现 failover，否则是需要修改 transfer 的配置的。因此 Satori 中坚持用单点的方式来部署，然后通过配合公网提供的 APM 服务保证可用性。真的希望有高可用的话，riemann 和 alarm 可以部署两份，通过 keepalived 的方式来实现，InfluxDB 可以官方的 Relay 来实现。

架构图

与 Open-Falcon 的比较

	Satori	Open-Falcon
agent	支持按照正则表达式排除 metric 支持从 agent 上附加固定的 tag 支持 cgroups 限制自身资源占用 更方便的插件更新机制 内置自更新功能（ops-updator） 支持带参数的插件 去除了 push 和 plugin 以外的所有 http 接口	可以单机部署
transfer	支持发送到 influxdb [1] 支持发送到 riemann 支持发送到 transfer [2] 重构了发送端的代码，现在代码比之前容易维护了	可以配合原版 graph 和 judge 运行
alarm	弃用了 Open-Falcon 的 alarm，完全重写 支持 EVENT 类型（只报警不记录状态） 支持多种报警后端，并且易于扩展 [3] Mac 下有好用的 BitBar 插件	支持报警合并
sender	已经合并进了 alarm 中
links	移除了 [4]
graph	替换成 InfluxDB 了
query	移除了
dashboard	替换成 Grafana 了
task	InfluxDB 自带 task 的功能
aggreagator	规则中有 aggregate 和 slot-window 实现相同功能
nodata	规则中有 watchdog 实现相同功能
portal	移除了，所有信息通过规则仓库管理
gateway	合并进了 transfer
master	没有数据库依赖	在 Open-Falcon 叫 hbs
portal	移除了，所有信息通过规则仓库管理
frontend	完全重写，采用了纯前端的方案	对应 Open-Falcon 中的 fe
InfluxDB	开源组件，用来存储和查询收集上来的监控信息	Open-Falcon 中不存在
riemann	开源组件，负责报警判定和产生插件规则	Open-Falcon 中不存在
Grafana	开源组件，替换了 graph	对应 Open-Falcon 中的 dashboard
nginx	为前端页面提供服务	Open-Falcon 中不存在

[1]	使用了 hitripod 的补丁

[2]	即 Open-Falcon 中 gateway 的功能

[3]	电话、短信、BearyChat、OneAlert、PagerDuty、邮件、微信企业号

[4]	推荐直接使用低优先级的通道（如 BearyChat/其他IM，或者 BitBar）， 或者在规则中做聚合（参见 复杂需求 ），不做报警合并。

注解

与 Open-Falcon 的比较是基于 v0.1 的，很多东西对 Falcon-Plus 不再适用了