Prometheus 架构

上一小节，通过部署 Node Exporter 我们成功的获取到了当前主机的资源使用情况。接下来我们将从 Prometheus 的架构角度详细介绍 Prometheus 生态中的各个组件。

下图展示 Prometheus 的基本架构：

Prometheus 架构

Prometheus Server

Prometheus Server 是 Prometheus 组件中的核心部分，负责实现对监控数据的获取，存储以及查询。 Prometheus Server 可以通过静态配置管理监控目标，也可以配合使用 Service Discovery 的方式动态管理监控目标，并从这些监控目标中获取数据。其次 Prometheus Server 需要对采集到的监控数据进行存储，Prometheus Server 本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。最后 Prometheus Server 对外提供了自定义的 PromQL 语言，实现对数据的查询以及分析。

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

Prometheus Server 的联邦集群能力可以使其从其他的 Prometheus Server 实例中获取数据，因此在大规模监控的情况下，可以通过联邦集群以及功能分区的方式对Prometheus Server 进行扩展。

Exporters

Exporter 将监控数据采集的端点通过 HTTP 服务的形式暴露给 Prometheus Server，Prometheus Server 通过访问该 Exporter 提供的 Endpoint 端点，即可获取到需要采集的监控数据。

一般来说可以将 Exporter 分为2类：

• 直接采集：这一类 Exporter 直接内置了对 Prometheus 监控的支持，比如cAdvisor，Kubernetes，Etcd，Gokit 等，都直接内置了用于向 Prometheus 暴露监控数据的端点。
• 间接采集：间接采集，原有监控目标并不直接支持 Prometheus，因此我们需要通过 Prometheus 提供的Client Library编写该监控目标的监控采集程序。例如： Mysql Exporter，JMX Exporter，Consul Exporter等。

AlertManager

在 Prometheus Server 中支持基于 PromQL 创建告警规则，如果满足 PromQL 定义的规则，则会产生一条告警，而告警的后续处理流程则由 AlertManager 进行管理。在AlertManager 中我们可以与邮件，Slack 等等内置的通知方式进行集成，也可以通过Webhook自定义告警处理方式。AlertManager 即 Prometheus 体系中的告警处理中心。

PushGateway

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