云原生时代开源监控软件Prometheus架构介绍

Posted 2023-02-24

作为云原生时代应用系统监控的利器，Prometheus的整体架构如下所示：

Prometheus架构图

上图说明了Prometheus的整体架构，Prometheus可以直接通过目标拉取数据（架构图左下角），或者间接地通过中间网关（架构图左上角Push gateway）拉取数据。它在本地存储抓取的所有数据，并通过规则从现有数据中聚合记录新的时间序列或者产生警告(架构图中间和右上角)，可以通过 ​​Grafana​​或者其他工具来实现监控数据的可视化（架构图右下角）。

4.1. Prometheus Server端

图4-2 Prometheus Server端架构图

Prometheus Server端是Prometheus的核心。Prometheus本身是一个以进程方式启动，之后以多进程和多线程实现监控数据收集、计算、查询、更新、存储的一个C/S模型运行模式。

TSDB

Prometheus采用的是时间序列（time-series）的方式，以一种自定义的格式存储在本地硬盘上。Prometheus的本地时间序列数据库以每两小时为间隔来分块（block）存储，每一个块中又分为多个chunk文件，chunk文件是用来存放采集过来的数据的时间序列数据，元数据（metadata）和索引文件（index），索引文件是对指标（metrics）和标签（labels）进行索引后存储在chunk中，chunk是作为存储的基本单位，索引和元数据作为子集。

Prometheus平时是将采集过来的数据先都存放在内存之中以类似缓存的方式用于加快搜索和访问。当出现宕机时，Prometheus有一种保护机制叫做WAL（类似Oracle归档日志），可以将数据定期存入硬盘中，以Chunk来表示，并在重新启动时，用以恢复进内存。

Retrieval

用于将抓取（pull）的数据存入到TSDB中。HTTP server

展示端以HTTP的方式从TSDB中获取监控数据。

4.2. 服务发现

图4-3 Prometheus服务发现

Prometheus可以与其它开源的注册中心（例如Consul）组件进行集成实现自动服务发现功能，另外它还能通过定义配置文件来给Prometheus本身规定需要被监控的项目和被监控的节点。

4.3. 采集客户端

图4-4 Prometheus采集数据方式

客户端主要有两种方式采集监控数据：

Pull-主动拉取方式

Pull主动拉取方式主要分三种类型：

Exporters：客户端（被监控机器）先安装各类已有exporters（由社区或企业、开发的监控客户端插件）在系统上，exporters以守护进程的模式运行并开始采集数据，由于exporter本身是一个http_server，Prometheus可以用pull的方式（Http get）主动去访问每个节点上exporter并采集回需要的数据（K-V形式的监控数据）；

Jobs：应用系统通过集成Prometheus的形式，开发符合Prometheus接口规范的监控数据查询接口供Prometheus服务端拉取采集的监控数据；

Push gateway：Prometheus服务端以pull的方式从Push gateway中采集需要的监控数据；

Push-被动推送方式

此种方式适用于临时性的监控任务，应用系统运行自己开发的各种脚本，把监控数据组织成k-v的形式发送给push gateway之后，Prometheus服务端再通过pull方式从push gateway中获取推送的监控数据。这种采集方式相对于Prometheus服务端是一种被动的数据采集模式。

4.4. 报警端

图4-5 Prometheus报警端

报警端（Alertmanager）是用于监控数据的报警模块，支持通过多种方式去发送预警，比如短信、邮件、企业微信、钉钉等。Prometheus的警报数据是在 Prometheus服务端中依据配置的警报规则(Alert Rule)计算并产生，当产生报警信息时会将报警信息推送给altermanager，由altermanager通过配置的渠道将报警信息发送给相关人员。

Alertmanager的目标不是简单地“发出警报”，而是“发出高质量的警报”。它提供的高级功能包括但不限于：

可以通过模板渲染警报内容；

通过配置参数管理警报的重复提醒时机与消除后消除通知的发送；

根据标签定义警报路由，实现警报的优先级、接收人划分，并针对不同的优先级和接收人定制不同的发送策略；

将同类型警报打包成一条通知发送出去，降低警报通知的频率；

支持静默规则: 用户可以定义一条静默规则，在一段时间内停止发送部分特定的警报；

支持“抑制”规则(Inhibition Rule): 用户可以定义一条“抑制”规则，规定在某种警报发生时，不发送另一种警报；

4.5. 可视化端

图4-6 Prometheus展示端

Prometheus本身自带了图形成型界面Prometheus UI，Prometheus UI提供了基本的数据可视化能力，可以帮助用户直接使用PromQL查询数据，并将数据通过可视化图表的方式进行展示，如下图所示：

图4-7 Prometheus UI展示举例

此图表展现方式单一，满足不了人们对可视化的要求，Prometheus通过与 Grafana集成，解决了Prometheus可视化的需求，Grafana展示效果如下图所示：

图4-8 Grafana展示页面举例

Grafana除了提供灵活的可视化定制能力以外，还提供了面向企业的组织级管理能力。在Grafana中Dashboard是属于一个组织，通过组织，可以在更大规模上使用Grafana，例如对于一个企业而言，我们可以创建多个组织，其中一个用户可以属于一个或多个不同的组织。 并且在不同的组织下，可以为用户赋予不同的权限。 从而可以有效的根据企业的组织架构定义整个管理模型。

4.6. Prometheus Server集群

Prometheus Server集群方案通过部署多套Prometheus Server，采集相同的Targets即可实现。

基于此模式只能确保Prometheus服务的可用性问题，但是不解决Prometheus Server之间的数据一致性问题以及持久化问题（数据丢失后无法恢复），也无法进行动态的扩展。因此这种部署方式适合监控规模不大，Prometheus Server也不会频繁发生迁移的情况，并且只需要确保短周期监控数据的场景。

图4-9 Prometheus Server高可用架构示意图

4.7. 远程存储

Prometheus的本地存储设计可以减少其自身运维和管理的复杂度，同时能够满足大部分用户监控规模的需求。但是本地存储也意味着Prometheus无法持久化数据，无法存储大量历史数据，同时也无法灵活扩展和迁移。

为了保持Prometheus的简单性，Prometheus并没有尝试在自身中解决以上问题，而是通过定义两个标准接口（remote_write/remote_read），让用户可以基于这两个接口将数据保存到任意第三方的存储服务中，这种方式在Prometheus中称为远程存储。

图4-10  Prometheus Server对接第三方存储示意图

4.8. Alertmanager集群

Prometheus Server高可用的情况下，单个alertmanager容易引发单点故障，解决该问题的直接方式就是部署多套Alertmanager,但是由于Alertmanager之间存在并不了解彼此的情况，因此会引发报警通知被不同的Alertmanager重复发送多次的问题。为了解决这一问题，Alertmanager引入了Gossip机制，保证多个Alertmanager之间的信息传递，确保多个Alertmanager分别接收到相同报警信息的情况下，也只有一个报警通知被发送给接收方。

图4-11  Alertmanager集群架构示意图

Gossip协议是分布式系统中被广泛使用的协议，用于实现分布式节点之间的信息交换和状态同步。当报警信息发送完成后，Gossip会通知其他Alertmanager实例当前报警已经发送，其它实例收到Gossip信息后，则会在自己的数据库中保存该通知已发送的记录而不再对外发送相同的信息。

Alertmanager基于Gossip实现的集群机制虽然不能保证所有实例上的数据时刻保持一致，但是实现了CAP理论中的AP，即可用性和分区容错性，同时对于Prometheus Server而言保持了配置简单，Prometheus Server之间不需要任何的状态同步。

4.9. 联邦集群

由于Prometheus基于Pull模型，当有大量的Target需要采集样本时，单一Prometheus实例在抓取数据时会出现性能问题，联邦集群的特性可以让Prometheus将样本采集任务划分到不同的Prometheus实例中，并且通过一个统一的中心节点进行聚合，从而可以使Prometheus根据规模进行扩展。

图4-12 Prometheus联邦集群架构示意图

如上图所示，将监控目标分成不同的区域，每个区域部署单独的Prometheus Server，用于采集当前区域的监控数据。并由一个中心的Prometheus Server负责聚合多个区域的监控数据。这一特性在Prometheus中称为联邦集群。