作者 | 凯文Garnett 责编 | 张文

头图 | CSDN 下载自视觉中国

面试广度，深度都很重要，多扩展知识面总是好的！今天就让我们来瞅瞅这个被号称是下一代监控的 Prometheus！

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

接下来的文章打算围绕 Prometheus 做一个系列的介绍，顺便也帮自己理清一下知识点。

在 Prometheus 之前市面已经出现了很多的监控系统，如 Zabbix、Open-Falcon 等。那么 Prometheus 和这些监控系统有啥异同呢？我们在这就介绍下 Zabbix 这个监控系统。

Zabbix 是由 Alexei Vladishev 开源的分布式监控系统，支持多种采集方式和采集客户端，同时支持 SNMP、IPMI、JMX、Telnet、SSH 等多种协议，它将采集到的数据存放到数据库中，然后对其进行分析整理，如果符合告警规则，则触发相应的告警。

Zabbix 核心组件主要是 Agent 和 Server。其中 Agent 主要负责采集数据并通过主动或者被动的方式采集数据发送到 Server/Proxy，除此之外，为了扩展监控项，Agent 还支持执行自定义脚本。Server 主要负责接收 Agent 发送的监控信息，并进行汇总存储，触发告警等。

为了便于快速高效的配置 Zabbix 监控项，Zabbix 提供了模板机制，从而实现批量配置的目的。

Zabbix Server 将收集的监控数据存储到 Zabbix Database 中。Zabbix Database 支持常用的关系型数据库，例如 MySQL、PostgreSQL、Oracle 等，默认 MySQL。Zabbix Web 页面（PHP 编写）负责数据查询。

Zabbix 由于使用了关系型数据存储时序数据，所以在监控大规模集群时常常在数据存储方面捉襟见肘。为此 Zabbix 4.2 版本后也开始支持时序数据存储，不过目前还不成熟。

Open-Falcon 是小米开源的企业级监控工具，用 Go 语言开发而成，包括小米、滴滴、美团等在内的互联网公司都在使用它，是一款灵活、可扩展并且高性能的监控方案，在这里就不多做介绍了。

下表通过多维度展现了各自监控系统的优缺点：

Prometheus 是一套开源的系统监控报警框架。它受启发于 Google 的 Brogmon 监控系统，由工作在 SoundCloud 的前 google 员工在 2012 年创建，作为社区开源项目进行开发，并于 2015 年正式发布。

2016 年，Prometheus 正式加入 Cloud Native Computing Foundation（CNCF）基金会的项目，成为受欢迎度仅次于 Kubernetes 的项目。2017 年底发布了基于全新存储层的 2.0 版本，能更好地与容器平台、云平台配合。

Prometheus 作为新一代的云原生监控系统，目前已经有超过 650+位贡献者参与到 Prometheus 的研发工作上，并且超过 120+项的第三方集成。

Prometheus 的生态系统包括多个组件，大部分的组件都是用 Go 语言编写的，因此部署非常方便，而这些组件大部分都是可选的，主要组件介绍如下：

Prometheus Server 是 Prometheus 组件中的核心部分，负责实现对监控数据的获取，存储以及查询。Prometheus Server 可以通过静态配置管理监控目标，也可以配合使用 Service Discovery 的方式动态管理监控目标，并从这些监控目标中获取数据。

其次，Prometheus Server 需要对采集到的监控数据进行存储，Prometheus Server 本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。

最后，Prometheus Server 对外提供了自定义的 PromQL 语言，实现对数据的查询以及分析。

Prometheus Server 内置的 Express Browser UI，通过这个 UI 可以直接通过 PromQL 实现数据的查询以及可视化。

主要是实现接收由 Client push 过来的指标数据，在指定的时间间隔，由主程序来抓取。

由于 Prometheus 数据采集基于 Pull 模型进行设计，因此在网络环境的配置上必须要让 Prometheus Server 能够直接与 Exporter 进行通信。当这种网络需求无法直接满足时，就可以利用 PushGateway 来进行中转。可以通过 PushGateway 将内部网络的监控数据主动 Push 到 Gateway 当中。而 Prometheus Server 则可以采用同样 Pull 的方式从 PushGateway 中获取到监控数据。

主要用来采集数据，并通过 HTTP 服务的形式暴露给 Prometheus Server，Prometheus Server 通过访问该 Exporter 提供的接口，即可获取到需要采集的监控数据。常见的Exporter有很多，例如node_exporter、mysqld_exporter、haproxy_exporter 等，支持如 HAProxy、StatsD、Graphite、Redis 此类的服务监控；

管理告警，主要是负责实现报警功能。在 Prometheus Server 中支持基于 PromQL 创建告警规则，如果满足PromQL定义的规则，则会产生一条告警，而告警的后续处理流程则由 AlertManager 进行管理。

在 AlertManager 中我们可以与邮件，Slack 等等内置的通知方式进行集成，也可以通过 Webhook 自定义告警处理方式。AlertManager 即 Prometheus 体系中的告警处理中心。

上图是 Prometheus 整体架构图，左侧是各种符合 Prometheus 数据格式的 exporter，除此之外为了支持推动数据类型的 Agent，可以通过 Pushgateway 组件，将 Push 转化为 Pull。

Prometheus 甚至可以从其它的 Prometheus 获取数据，组建联邦集群。Prometheus 的基本原理是通过 HTTP 周期性抓取被监控组件的状态，任意组件只要提供对应的 HTTP 接口并且符合 Prometheus 定义的数据格式，就可以接入 Prometheus 监控。

上侧是服务发现，Prometheus 支持监控对象的自动发现机制，从而可以动态获取监控对象。

图片中间是 Prometheus Server，Retrieval 模块定时拉取数据，并通过 Storage 模块保存数据。

PromQL 为 Prometheus 提供的查询语法，PromQL 模块通过解析语法树，调用 Storage 模块查询接口获取监控数据。

图片右侧是告警和页面展现，Prometheus 将告警推送到 alertmanger，然后通过 alertmanger 对告警进行处理并执行相应动作。

数据展现除了 Prometheus 自带的 WebUI，还可以通过 Grafana 等组件查询 Prometheus 监控数据。

Prometheus Server 负载定时在目标上抓取 metrics(指标)数据，每个抓取目标都需要暴露一个 HTTP 服务接口用于 Prometheus 定时抓取。这种调用被监控对象获取监控数据的方式被称为 Pull(拉)。Pull 方式体现了 Prometheus 独特的设计哲学与大多数采用 Push(推)方式的监控不同

Pull 方式的优势是能够自动进行上游监控和水平监控，配置更少，更容易扩展，更灵活，更容易实现高可用。简单来说就是 Pull 方式可以降低耦合。由于在推送系统中很容易出现因为向监控系统推送数据失败而导致被监控系统瘫痪的问题。所以通过 Pull 方式，被采集端无需感知监控系统的存在，完全独立于监控系统之外，这样数据的采集完全由监控系统控制

至此，我们了解了一些监控系统的区别和优缺点，也分析了 prometheus 的组件和它的整体架构，下篇将会更加深入的了解 Prometheus，可不要错过哦！