内容摘要：这篇文章，我将对监控体系的基础知识、原理和架构做一次系统性整理，同时还会对几款最常用的开源监控产品做下介绍，以便大家选型时参考。内容包括3部分：必知必会的监控基础知识主流监控系统介绍监控系统的选型建议

这篇文章
 ，监控我将对监控体系的系统选型基础知识、原理和架构做一次系统性整理，篇全同时还会对几款最常用的搞定开源监控产品做下介绍
 ，以便大家选型时参考。监控内容包括3部分 ：

必知必会的系统选型监控基础知识主流监控系统介绍监控系统的选型建议

必知必会的监控基础知识

我们可以理解监控系统就像我们古代打战的哨兵一样，哨兵的篇全角色非常重要，敌人来了 ，搞定哨兵会第一时间发出预警(吹笛、监控打鼓、免费模板系统选型放烟) ，篇全让守城的搞定战士能够最快的时间处理 ，应对。监控

那对于我们应用系统而言，系统选型监控系统就像我们第三只眼 ，篇全如果有应用系统出现问题，我们可以通过监控系统看是哪里出现问题，是redis挂了，还是说服务器内存满了，有监控系统我们可以很轻松、快速的高防服务器定位问题 。

甚至我们可以设置预警，对一些将要出现的问题进行提前预防处理 ，及时避免问题的发生。

1 、监控系统的作用

帮助定位故障: 在发生故障时，我们可以通过查看监控系统的各项指标数据
，辅助故障分析和定位
。预警减少故障率: 对于即将可能产生的故障能够及时发出预警信息，做好提前预防处理。辅助容量规划: 为服务器、源码下载中间件以及应用集群的容量规划提供数据支撑。辅助性能调优: JVM垃圾回收次数、接口响应时间、慢SQL等等都可以监控优化。2、常见的监控对象和指标都有哪些 ？服务器监控: CPU使用率、内存使用率、磁盘使用率、磁盘读写的吞吐量、网络出入流量等等  。MySQL监控: TPS、QPS
、数据库连接数 、香港云服务器慢SQL、InnoDB缓冲池命中率等等 。Redis监控: 内存使用率 、缓存命中率、key值总数
、Redis响应请求时间、客户端连接数
、持久性指标等等
。MQ监控: 连接数、队列数、生产速率 、消费速率、消息堆积量等等。应用监控:

HTTP接口
：URL存活 、请求量、耗时 、模板下载异常量

JVM 
：GC次数
、GC耗时 、各个内存区域的大小、当前线程数 、死锁线程数

线程池：活跃线程数
、任务队列大小 、任务执行耗时、拒绝任务数

3
、监控系统的基本流程

数据采集：采集的方式有很多种 ，包括日志埋点进行采集，JMX标准接口输出监控指标，被监控对象提供REST API进行数据采集（如Hadoop、ES），源码库系统命令行 ，统一的SDK进行侵入式的埋点和上报等。数据传输：将采集的数据以TCP、UDP或者HTTP协议的形式上报给监控系统 ，有主动Push模式，也有被动Pull模式 。数据存储：有使用MySQL
、Oracle等关系数据库存储的
，也有使用时序数据库RRDTool、OpentTSDB 、InfluxDB存储的 ，还有使用HBase存储的 
。数据展示 ：数据指标的图形化展示。监控告警
：灵活的告警设置 ，以及支持邮件、短信 、IM等多种通知通道。

市面上的一些常见监控系统比较

下面再来认识下主流的开源监控系统，由于篇幅有限，我挑选了3款使用最广泛的监控系统：Zabbix 、Open-Falcon、Prometheus ，会对它们的架构进行介绍
，同时总结下各自的优劣势。

1 、Zabbix介绍

Zabbix 1998年诞生 ，核心组件采用C语言开发 ，Web端采用PHP开发。它属于老牌监控系统中的优秀代表 ，监控功能很全面，使用也很广泛 ，差不多有70%左右的互联网公司都曾使用过 Zabbix 作为监控解决方案。

先来了解下Zabbix的架构设计：

Zabbix Server ：核心组件，C语言编写
，负责接收Agent 、Proxy发送的监控数据。同时，它还负责数据的汇总存储以及告警触发等。Zabbix Proxy：可选组件，对于被监控机器较多的情况下
，可使用Proxy进行分布式监控，它能代理Server收集部分监控数据
，以减轻Server的压力。Zabbix Agentd：部署在被监控主机上 ，用于采集本机的数据并发送给Proxy或者Server 。数据收集方式同时支持主动Push和被动Pull 两种模式
。Database：用于存储配置信息以及采集到的数据，支持MySQL、Oracle等关系型数据库 。同时 ，最新版本的Zabbix已经开始支持时序数据库，不过成熟度还不高。Web Server
：Zabbix的GUI组件 ，PHP编写 ，提供监控数据的展现和告警配置。

Zabbix的优势：

产品成熟：由于诞生时间长且使用广泛，拥有丰富的文档资料以及各种开源的数据采集插件 ，能覆盖绝大部分监控场景。采集方式丰富
：支持Agent 、SNMP  、JMX
、SSH等多种采集方式 ，以及主动和被动的数据传输方式
。

Zabbix的劣势：

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

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

Open-falcon 是小米2015年开源的企业级监控工具，采用Go和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中查询指标数据，汇总结果后统一返回给用户，屏蔽了存储集群的分片细节。

复制Open-Falcon优势1. 自动采集能力
：Falcon-agent 能自动采集服务器的200多个基础指标（比如CPU、内存等）
，无需在server上做任何配置 ，这一点可以秒杀Zabbix.强大的存储能力：底层采用RRDTool，并且通过一致性hash进行数据分片 ，构建了一个分布式的时序数据存储系统 ，可扩展性强 。灵活的数据模型
：借鉴OpenTSDB，数据模型中引入了tag，这样能支持多维度的聚合统计以及告警规则设置，大大提高了使用效率。插件统一管理：Open-Falcon的插件机制实现了对用户自定义脚本的统一化管理 ，可通过HeartBeat Server分发给agent
，减轻了使用者自主维护脚本的成本。个性化监控支持 ：基于Proxy-gateway ，很容易通过自主埋点实现应用层的监控（比如监控接口的访问量和耗时）和其他个性化监控需求，集成方便。 复制Open-Falcon缺点1. 监控类型较少: 不支持常用应用服务器如tomcat、apache、jetty等的监控。整体发展一般 ，社区活跃度低: 没有专门的运维支持
，代码更新较少
，没有一个较大的社区来维护，后续想要有什么新的能力基本只能指望自己扩展 。3、Prometheus（号称下一代监控系统）

我们知道 zabbix 在监控界占有不可撼动的地位 ，功能强大。但是对容器监控显得力不从心 。为解决监控容器的问题，引入了 Prometheus 技术
。

Prometheus 是一套开源的系统监控报警框架 。是由前google员工2015年正式发布的开源监控系统，采用Go语言开发
。它不仅有一个很酷的名字 
，同时它有Google与k8s的强力支持 ，开源社区异常火爆 。

先来了解下Prometheus的架构设计
：

Exporter：主要用来采集数据  ，并通过 HTTP 服务的形式暴露给 Prometheus Server，Prometheus Server 通过访问该 Exporter 提供的接口，即可获取到需要采集的监控数据 。常见的Exporter有很多，例如node_exporter、mysqld_exporter 、redis_exporter 等Prometheus Server
：核心组件，负责实现对监控数据的获取，存储以及查询 。Prometheus Server 也是一个时序数据库，它将监控数据保存在本地磁盘中，并对外提供自定义的 PromQL 语言实现对数据的查询和分析。Push gateway：由于 Prometheus 数据采集采用 pull 方式进行设置的， 内置必须保证 prometheus server 和对应的 exporter 必须通信，当网络情况无法直接满足时 ，可以使用 pushgateway 来进行中转 ，可以通过 pushgateway 将内部网络数据主动 push 到 gateway 里面去
，而 prometheus 采用 pull方式拉取 pushgateway 中数据。Alert Manager：当支持基于 PromQL 创建告警规则，如果满足定义的规则 ，则会产生一条告警信息，进入 AlertManager 进行处理 。可以集成邮件，微信或者通过 webhook 自定义报警。Web UI：Prometheus内置了一个简单的web控制台 ，可以查询配置信息和指标等 ，而实际应用中我们通常会将Prometheus作为Grafana的数据源，创建仪表盘以及查看指标 。 复制Prometheus优点1.

社区活跃度高: github start超过40k，且一直在维护。

基于时序数据库 ，存储效率高:Prometheus核心部分只有一个单独的二进制文件，不存在任何的第三方依赖(数据库，缓存等等)。唯一需要的就是 本地磁盘
，因此不会有潜在级联故障的风险 。

很好地支持容器监控: 能自动发现容器，同时k8s和etcd等项目都提供了对Prometheus的原生支持，是目前容器监控最流行的方案 。

基于Pull模型的架构: Prometheus基于Pull模型的架构方式 
，可以在任何地方（本地电脑 ，开发环境，测试环境）搭建我们的监控系统
。

复制Prometheus缺点1.

Prometheus 是基于 Metric 的监控 ，不适用于日志（Logs）
、事件(Event)、调用链(Tracing) 。

由于Prometheus采用的是Pull模型拉取数据，意味着所有被监控的endpoint必须是可达的，需要合理规划网络的安全配置 。

指标众多，需进行适当裁剪。

选型建议

通过上面的介绍，大家对主流的监控系统应该有了一定的认识。面对选型问题，我的建议是：

1、先明确清楚你的监控需求 ：要监控的对象有哪些？机器数量和监控指标有多少 ？需要具备什么样的告警功能？

2 
、监控是一项长期建设的事情，一开始就想做一个 All In One 的监控解决方案，我觉得没有必要。从成本角度考虑 ，在初期直接使用开源的监控方案即可，先解决有无问题。

3 、从系统成熟度上看，Zabbix属于老牌的监控系统 ，资料多
，功能全面且稳定
，如果机器数量在几百台以内，不用太担心性能问题，另外 ，采用数据库分区
、SSD硬盘 、Proxy架构 、Push采集模式都可以提高监控性能。

4、Zabbix在服务器监控方面占绝对优势，可以满足90%以上的监控场景 ，但是应用层的监控似乎并不擅长，比如要监控线程池的状态、某个内部接口的执行时间等
，这种通常都要做侵入式埋点。相反 ，新一代的监控系统Open-Falcon和Prometheus在这一点做得很好。

5、从整体表现上来看 ，新一代监控系统也有明显的优势 ，比如：灵活的数据模型、更成熟的时序数据库、强大的告警功能
，如果之前对zabbix这种传统监控没有技术积累 ，建议使用Open-Falcon或者Prometheus.

6、Open-Falcon的核心优势在于数据分片功能 ，能支撑更多的机器和监控项；Prometheus则是容器监控方面的标配，有Google和k8s加持。

7、Zabbix、Open-Falcon和Prometheus都支持和Grafana做快速集成，想要美观且强大的可视化体验，可以和Grafana进行组合。

8、用合适的监控系统解决相应的问题即可，可以多套监控同时使用 ，这种在企业初期很常见。

9、到中后期 ，随着机器数据增加和个性化需求增多（比如希望统一监控平台 、打通公司的CMDB和组织架构关系），往往需要二次开发或者通过监控系统提供的API做集成 ，从这点来看  ，Open-Falcon或者Prometheus更合适。

10 、如果非要自研，可以多研究下主流监控系统的架构方案 ，借鉴它们的优势 。