监控系统对比

开源监控系统也经历了非常多的迭代：

• 老牌监控系统：Zabbix, Nagios, Cacti, Ganglia, Garafana
• 新型监控系统：Open-Falcon, Prometheus

Zabbix

Zabbix 是由 Alexei Vladishev 开源的分布式监控系统，支持多种采集方式和采集客户端，同时支持 SNMP、IPMI、JMX、Telnet、SSH 等多种协议，它将采集到的数据存放到数据库中，然后对其进行分析整理，如果符合告警规则，则触发相应的告警。Zabbix 1998 年诞生，核心组件采用 C 语言开发，Web 端采用 PHP 开发。它属于老牌监控系统中的优秀代表，监控功能很全面，使用也很广泛，差不多有 70%左右的互联网公司都曾使用过 Zabbix 作为监控解决方案。

Zabbix Server 将收集的监控数据存储到 Zabbix Database 中。Zabbix Database 支持常用的关系型数据库，例如 MySQL、PostgreSQL、Oracle 等，默认 MySQL。Zabbix Web 页面（PHP 编写）负责数据查询。Zabbix 由于使用了关系型数据存储时序数据，所以在监控大规模集群时常常在数据存储方面捉襟见肘。为此 Zabbix 4.2 版本后也开始支持时序数据存储，不过目前还不成熟。Zabbix 的架构设计如下：

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

优势

• **产品成熟：**由于诞生时间长且使用广泛，拥有丰富的文档资料以及各种开源的数据采集插件，能覆盖绝大部分监控场景。
• **采集方式丰富：**支持 Agent、SNMP、JMX、SSH 等多种采集方式，以及主动和被动的数据传输方式。
• 较强的扩展性：支持 Proxy 分布式监控，有 agent 自动发现功能，插件式架构支持用户自定义数据采集脚本。
• 配置管理方便：能通过 Web 界面进行监控和告警配置，操作方便，上手简单。

缺陷

• 性能瓶颈：机器量或者业务量大了后，关系型数据库的写入一定是瓶颈，官方给出的单机上限是 5000 台，个人感觉达不到，尤其现在应用层的指标越来越多。虽然最新版已经开始支持时序数据库，不过成熟度还不高。
• **应用层监控支持有限：**如果想对应用程序做侵入式的埋点和采集（比如监控线程池或者接口性能），zabbix 没有提供对应的 sdk，通过插件式的脚本也能曲线实现此功能，个人感觉 zabbix 就不是做这个事的。
• 数据模型不强大：不支持 tag，因此没法按多维度进行聚合统计和告警配置，使用起来不灵活。
• 方便二次开发难度大：Zabbix 采用的是 C 语言，二次开发往往需要熟悉它的数据表结构，基于它提供的 API 更多只能做展示层的定制。

ELK 监控生态

ELK (Elasticsearch,Logstash,Kibana) 是 Elastic 公司提供的三个开源组件。在日常工作中，我们需要进行日志分析场景：直接对日志文件进行 grep、awk 等正则操作，获取我们想要的信息。在大规模的场景中，日志文件分布在不同的服务器上，且文件非常大，逐台操作性能非常低。比如 Nginx 日志，Mysql 慢查询日志，应用 log 日志等。ELK 提供一整套的解决方案，可以帮助我们快速全站查询。

下图是 Mysql 慢查询的截图，通过 Python 脚本，可以实时读取 Mysql 慢查询日志，并写入 ES，方便查看线上问题。

下图是服务器的 dashboard，通过模糊匹配，可以快速查询相关服务器组的性能指标。

Open-Falcon

Open-Falcon 是小米开源的监控系统，灵活的数据采集，水平扩展能力以及高效的告警策略帮助我们快速监控服务端的信息。小米初期也使用的 Zabbix 进行监控，但是机器量和业务量上来后，Zabbix 就有些力不从心了。因此，后来自主研发了 Open-Falcon，在架构设计上吸取了 Zabbix 的经验，同时很好地解决了 Zabbix 的诸多痛点。

Open-Falcon 用 Go 语言开发而成，包括小米、滴滴、美团等在内的互联网公司都在使用它，是一款灵活、可扩展并且高性能的监控方案，主要组件包括了：

• Falcon-agent：用 Go 语言开发的 Daemon 程序，运行在每台 Linux 服务器上，用于采集主机上的各种指标数据，主要包括 CPU、内存、磁盘、文件系统、内核参数、Socket 连接等，目前已经支持 200 多项监控指标。并且，Agent 支持用户自定义的监控脚本。

• Hearthbeat server：简称 HBS 心跳服务，每个 Agent 都会周期性地通过 RPC 方式将自己的状态上报给 HBS，主要包括主机名、主机 IP、Agent 版本和插件版本，Agent 还会从 HBS 获取自己需要执行的采集任务和自定义插件。

• Transfer：负责接收 Agent 发送的监控数据，并对数据进行整理，在过滤后通过一致性 Hash 算法发送到 Judge 或者 Graph。

• Graph：RRD 数据上报、归档、存储的组件。Graph 在收到数据以后，会以 RRDtool 的数据归档方式来存储，同时提供 RPC 方式的监控查询接口。

• Judge：告警模块，Transfer 转发到 Judge 的数据会触发用户设定的告警规则，如果满足，则会触发邮件、微信或者回调接口。这里为了避免重复告警引入了 Redis 暂存告警，从而完成告警的合并和抑制。

• Dashboard：面向用户的监控数据查询和告警配置界面。

优势

• 自动采集能力：Falcon-agent 能自动采集服务器的 200 多个基础指标（比如 CPU、内存等），无需在 server 上做任何配置，这一点可以秒杀 Zabbix.
• 强大的存储能力：底层采用 RRDTool，并且通过一致性 hash 进行数据分片，构建了一个分布式的时序数据存储系统，可扩展性强。
• **灵活的数据模型：**借鉴 OpenTSDB，数据模型中引入了 tag，这样能支持多维度的聚合统计以及告警规则设置，大大提高了使用效率。
• **插件统一管理：**Open-Falcon 的插件机制实现了对用户自定义脚本的统一化管理，可通过 HeartBeat Server 分发给 agent，减轻了使用者自主维护脚本的成本。
• 个性化监控支持：基于 Proxy-gateway，很容易通过自主埋点实现应用层的监控（比如监控接口的访问量和耗时）和其他个性化监控需求，集成方便。

缺陷

• **整体发展一般：**社区活跃度不算高，同时版本更新慢，有些大厂是基于它的稳定版本直接做二次开发的，关于以后的前景其实有点担忧。
• UI 不够友好：对于业务线的研发来说，可能只想便捷地完成告警配置和业务监控，但是它把机器分组、策略模板、模板继承等概念全部暴露在 UI 上，感觉在围绕这几个概念设计 UI，理解有点费劲。
• **安装比较复杂：**个人的亲身感受，由于它是从小米内部衍生出来的，虽然去掉了对小米内部系统的依赖，但是组件还是比较多，如果对整个架构不熟悉，安装很难一蹴而就。

Prometheus

Prometheus 是一套开源的监控、报警、时间序列数据库的组合；它的灵感来自谷歌的 Borgmon，一个实时的时间序列监控系统，Borgmon 使用这些时间序列数据来识别问题并发出警报。Prometheus 最初由前谷歌 SRE Matt T. Proud 开发，并转为一个研究项目。在 Proud 加入 SoundCloud 之后，他与另一位工程师 Julius Volz 合作开发了 Prometheus。后来其他开发人员陆续加入了这个项目，并在 SoundCloud 内部继续开发，最终于 2015 年 1 月公开发布。

Prometheus 的优势在于其易于安装使用，外部依赖较少；并且直接按照分布式、微服务架构模式进行设计，支持服务自动化发现与代码集成。Prometheus 能够自定义多维度的数据模型，内置强大的查询语句，搭配其丰富的社区扩展，能够轻松实现数据可视化。

Prometheus 由两个部分组成，一个是监控报警系统，另一个是自带的时序数据库（TSDB）。上图是 Prometheus 整体架构图，左侧是各种符合 Prometheus 数据格式的 exporter，除此之外为了支持推动数据类型的 Agent，可以通过 Pushgateway 组件，将 Push 转化为 Pull。Prometheus 甚至可以从其它的 Prometheus 获取数据，组建联邦集群。Prometheus 的基本原理是通过 HTTP 周期性抓取被监控组件的状态，任意组件只要提供对应的 HTTP 接口并且符合 Prometheus 定义的数据格式，就可以接入 Prometheus 监控。

• **Prometheus Server：**核心组件，用于收集、存储监控数据。它同时支持静态配置和通过 Service Discovery 动态发现来管理监控目标，并从监控目标中获取数据。此外，Prometheus Server 也是一个时序数据库，它将监控数据保存在本地磁盘中，并对外提供自定义的 PromQL 语言实现对数据的查询和分析。
• **Exporter：**用来采集数据，作用类似于 agent，区别在于 Prometheus 是基于 Pull 方式拉取采集数据的，因此，Exporter 通过 HTTP 服务的形式将监控数据按照标准格式暴露给 Prometheus Server，社区中已经有大量现成的 Exporter 可以直接使用，用户也可以使用各种语言的 client library 自定义实现。
• **Push gateway：**主要用于瞬时任务的场景，防止 Prometheus Server 来 pull 数据之前此类 Short-lived jobs 就已经执行完毕了，因此 job 可以采用 push 的方式将监控数据主动汇报给 Push gateway 缓存起来进行中转。
• **Alert Manager：**当告警产生时，Prometheus Server 将告警信息推送给 Alert Manager，由它发送告警信息给接收方。
• **Web UI：**Prometheus 内置了一个简单的 web 控制台，可以查询配置信息和指标等，而实际应用中我们通常会将 Prometheus 作为 Grafana 的数据源，创建仪表盘以及查看指标。

优势

• **轻量管理：**架构简单，不依赖外部存储，单个服务器节点可直接工作，二进制文件启动即可，属于轻量级的 Server，便于迁移和维护。
• 较强的处理能力：监控数据直接存储在 Prometheus Server 本地的时序数据库中，单个实例可以处理数百万的 metrics。
• **灵活的数据模型：**同 Open-Falcon，引入了 tag，属于多维数据模型，聚合统计更方便。
• **强大的查询语句：**PromQL 允许在同一个查询语句中，对多个 metrics 进行加法、连接和取分位值等操作。
• 很好地支持云环境：能自动发现容器，同时 K8s 和 etcd 等项目都提供了对 Prometheus 的原生支持，是目前容器监控最流行的方案。

缺陷

• **功能不够完善：**Prometheus 从一开始的架构设计就是要做到简单，不提供集群化方案，长期的持久化存储和用户管理，而这些是企业变大后所必须的特性，目前要做到这些只能在 Prometheus 之上进行扩展。
• 网络规划变复杂：由于 Prometheus 采用的是 Pull 模型拉取数据，意味着所有被监控的 endpoint 必须是可达的，需要合理规划网络的安全配置。

综合对比

从开发语言上看，为了应对高并发和快速迭代的需求，监控系统的开发语言已经慢慢从 C 语言转移到 Go。不得不说，Go 凭借简洁的语法和优雅的并发，在 Java 占据业务开发，C 占领底层开发的情况下，准确定位中间件开发需求，在当前开源中间件产品中被广泛应用。

从系统成熟度上看，Zabbix 是老牌的监控系统：Zabbix 是在 1998 年出现的，系统功能比较稳定，成熟度较高。而 Prometheus 和 Open-Falcon 都是最近几年才诞生的，虽然功能还在不断迭代更新，但站在巨人的肩膀之上，在架构设计上借鉴了很多老牌监控系统的经验。

从系统扩展性方面看，Zabbix 和 Open-Falcon 都可以自定义各种监控脚本，并且 Zabbix 不仅可以做到主动推送，还可以做到被动拉取，Prometheus 则定义了一套监控数据规范，并通过各种 exporter 扩展系统采集能力。

从数据存储方面来看，Zabbix 采用关系数据库保存，这极大限制了 Zabbix 采集的性能，Open-Falcon 采用 RDD 数据存储，并且可以对接到 OpenTSDB，而 Prometheus 自研一套高性能的时序数据库，在 V3 版本可以达到每秒千万级别的数据存储，通过对接第三方时序数据库扩展历史数据的存储。

从配置和维护的复杂度上看，Prometheus 只有一个核心 server 组件，一条命令便可以启动，相比而言，其他系统配置相对麻烦，尤其是 Open-Falcon。

从社区活跃度上看，目前 Zabbix 社区活跃度比较低，Open-Falcon 虽然也比较活跃，但基本都是国内的公司参与，Prometheus 在这方面占据绝对优势，社区活跃度最高，并且受到 CNCF 的支持，后期的发展值得期待。

从容器支持角度看，由于 Zabbix 出现得比较早，当时容器还没有诞生，自然对容器的支持也比较差。Open-Falcon 虽然提供了容器的监控，但支持力度有限。Prometheus 的动态发现机制，不仅可以支持 Swarm 原生集群，还支持 Kubernetes 容器集群的监控，是目前容器监控最好解决方案。Zabbix 在传统监控系统中，尤其是在服务器相关监控方面，占据绝对优势。伴随着容器的发展，Prometheus 开始成为主导及容器监控方面的标配，并且在未来可见的时间内被广泛应用。总体来说，对比各种监控系统的优劣，Prometheus 可以说是目前监控领域最锋利的“瑞士军刀”了。