一篇吃透监控系统：主流工具选型及落地场景参考( 二 ) _监控系统

核心组件，C语言编写，负责接收Agent、Proxy发送的监控数据。同时，它还负责数据的汇总存储以及告警触发等。

Zabbix Proxy

可选组件，对于被监控机器较多的情况下，可使用Proxy进行分布式监控，它能代理Server收集部分监控数据，以减轻Server的压力。

Zabbix Agentd

部署在被监控主机上，用于采集本机的数据并发送给Proxy或者Server 。数据收集方式同时支持主动Push和被动Pull 两种模式。

Database

用于存储配置信息以及采集到的数据，支持MySQL、Oracle等关系型数据库。同时，最新版本的Zabbix已经开始支持时序数据库，不过成熟度还不高。

Web Server

Zabbix的GUI组件，PHP编写，提供监控数据的展现和告警配置。

1）Zabbix的优势

产品成熟

由于诞生时间长且使用广泛，拥有丰富的文档资料以及各种开源的数据采集插件，能覆盖绝大部分监控场景。

采集方式丰富

支持Agent、SNMP、JMX、SSH等多种采集方式，以及主动和被动的数据传输方式。

2）Zabbix的劣势

需要在被监控主机上安装Agent，所有的数据都存在数据库里，产生的数据很大，瓶颈主要在数据库。

2、Open-Falcon（小米出品，国内流行）

文章插图

Open-falcon 是小米2015年开源的企业级监控工具，采用Go和Python/ target=_blank class=infotextkey>Python语言开发，这是一款灵活、高性能且易扩展的新一代监控方案，目前小米、美团、滴滴等超过200家公司在使用它。

小米初期也使用的Zabbix进行监控，但是机器量和业务量上来后，Zabbix就有些力不从心了。因此，后来自主研发了Open-Falcon，在架构设计上吸取了Zabbix的经验，同时很好地解决了Zabbix的诸多痛点。

文章插图

架构看去比Zabbix复杂多了，其实它也是基于Server---Agent的模式，只不过Server又给他划分了好几个组件，这个耦合性和扩展性都得到了明显提高。

Falcon-agent

数据采集器和收集器，Go开发，部署在被监控的机器上。就相当于Agent，用于采集机器负载监控指标数据如：CPU、内存、磁盘、IO、网络、端口等等大概有200多个这些都可以自定是否收集。

Transfer

数据分发组件，接收客户端发送的数据，分别发送给数据存储组件Graph和告警判定组件Judge，Graph和Judge均采用一致性hash做数据分片，以提高横向扩展能力。同时Transfer还支持将数据分发到OpenTSDB，用于历史归档。

Graph

数据存储组件，底层使用RRDTool（时序数据库）做单个指标的存储，并通过缓存、分批写入磁盘等方式进行了优化。据说一个graph实例能够处理8W+每秒的写入速率。

Judge和Alarm

告警组件，Judge对Transfer组件上报的数据进行实时计算，判断是否要产生告警事件，Alarm组件对告警事件进行收敛处理后，将告警消息推送给各个消息通道。

API

面向终端用户，收到查询请求后会去Graph中查询指标数据，汇总结果后统一返回给用户，屏蔽了存储集群的分片细节。

1）Open-Falcon优势

自动采集能力
Falcon-agent 能自动采集服务器的200多个基础指标（比如CPU、内存等），无需在server上做任何配置，这一点可以秒杀Zabbix.

强大的存储能力
底层采用RRDTool，并且通过一致性hash进行数据分片，构建了一个分布式的时序数据存储系统，可扩展性强。

灵活的数据模型
借鉴OpenTSDB，数据模型中引入了tag，这样能支持多维度的聚合统计以及告警规则设置，大大提高了使用效率。

插件统一管理
Open-Falcon的插件机制实现了对用户自定义脚本的统一化管理，可通过HeartBeat Server分发给agent，减轻了使用者自主维护脚本的成本。

个性化监控支持
基于Proxy-gateway，很容易通过自主埋点实现应用层的监控（比如监控接口的访问量和耗时）和其他个性化监控需求，集成方便。

2）Open-Falcon缺点

监控类型较少