今天学习了open-Falcon+Grafana，用途是对各设备、网元进行监控。下面做个初步的记录：
github地址：https://github.com/open-falcon-archive/of-release
优点我就不细说了，比zabbix要强大一些。

架构图：

falcon架构图.png

不过我觉得小米的这张部署图对结构更容易理解：

图片.png

基础组件：

agent：安装在每台被监控的实例上。两个作用，1.agent从hbs拉取配置信息。 2.进行数据采集和收集，并上传给transfer。
transfer：transfer是一个无状态的集群。transfer接收agent上报的数据，然后使用一致性哈希进行数据
分片、并把分片后的数据转发给graph、judge集群
center-status：是中心存储的统称。Open-Falcon用到的中心存储，包括Mysql、Redis(Memcached要被弃用)。Mysql主要用于存储配置信息(如HostGroup、报警策略、UIC信息、Screen信息等)、索引数据等，Redis主要被用作报警缓存队列。

作图链路：

graph：graph组件用于存储、归档作图数据，可以集群部署。每个graph实例会处理一个分片的数据:接收transfer发送来的分片数据，归档、存储、生成索引；接受query对该数据分片的查询请求。
query：数据分片存储在graph上，用户查询起来比较麻烦。query负责提供一个统一的查询入口、屏蔽数据分片的细节。query的使用场景主要有：(1)dashboard图表展示 (2)使用监控数据做二次开发。为了方便用户访问，建议将query集群挂载到一个域名下。考虑到高可用，query至少部署两个实例
dashboard：用户监控数据的图表展示，是一个web应用。

报警链路：

judge：judge用于实现报警策略的触发逻辑。
hbs：hbs是Open-Falcon的配置中心，负责 适配系统的配置信息、管理agent信息等。
portal：portal提供监控策略管理相关的UI，使用频率较低、系统负载很小。
uic：uic是用户信息管理中心，提供用户管理的UI，使用频率较低、系统负载较小。
alarm（sender）：alarm负责整理报警信息，使变成适合发送的形式。alarm做了一些报警合并相关的工作。sender负责将报警内容发送给最终用户。sender本身无状态，可以部署多个实例。
link：links负责报警合并后的详情展示工作。