Prometheus 入门（一）：架构和基本概念学习

目录：
  1. Prometheus 简介
  2. Prometheus 组成与架构
  3. Prometheus 的相关概念

---

近年来，随着容器技术的迅猛发展，Kubernetes 已然成为受大家热捧的容器集群管理系统。Prometheus 作为 CNCF 的重要成员，活跃度仅此于 Kubernetes，现已广泛应用于 Kubernetes 集群的监控系统中。

一、Prometheus 简介

Prometheus 是一套开源的系统监控报警框架。它始于2012年由 SoundCloud 创建，并作为社区开源项目进行开发。2016，Prometheus 正式加入 Cloud Native Computing Foundation (简称：CNCF)，成为受欢迎程度仅次于 Kubernetes 的项目。

作为新一代的监控系统，Prometheus 具有以下特点：

• 强大的多维数据库模型：
    1.时间序列数据通过 metric 名和【键/值】对来区分。
    2.所有的 metrics 都可以设置任意的多维标签。
    3.数据模型更随意，不需要刻意设置成以点分割的字符串。
    4.可以对数据模型进行聚合、切割、切片等操作。
    5.支持双精度浮点型，标签可以设为全 unicode。
• 灵活而强大的查询语言(PromQL，Query Language for Prometheus)：在同一个查询语句中，可以对多个 metrics 进行乘法、加法、连接、取分数位等操作。
• 易于管理：Prometheus server 是一个单独的二进制文件，可直接在本地工作，不依赖于分布式存储，即单个 Prometheus server 节点是自治的。
• 高效：平均每个采样点仅占 3.5 bytes，且一个 Prometheus server 可以处理数百万的 metrics。
• 使用 Pull(拉模式) 采集时间序列数据，可避免有问题的服务器向其推送坏的 metrics。
• 支持采用 push gateway 的方式将时间序列数据推送至 Prometheus server 端。
• 可通过服务发现和静态配置获取监控的 targets。
• 支持多种可视化图形界面。
• 易于伸缩。
• Federation 机制：允许一个 Prometheus server 获取另一个 Prometheus server 的 metrics。

需要指出的是，由于 Prometheus 采集数据可能会丢失，因此 Prometheus 不适用于对采集数据要求 100% 精确的场景，例如计费系统。但如果用于记录时间序列数据，Prometheus 是具有很大的查询优势。此外，Prometheus 适用于微服务框架。

二、Prometheus 组成与架构

Prometheus 生态圈中包含了多个组件，其中许多组件是可选的：

• Prometheus server：核心组件，用于抓取和存储时间序列数据。
• Client Libraries：客户端库，为需要监控的服务生成相应的 metrics 并暴露给 Prometheus server。当 Prometheus server 来 pull 时，直接返回实时状态的 metrics。
• Push gateway：主要用于短期的 jobs。由于这类 jobs 存活时间较短，可能在 Prometheus server 来 pull 之前就消失了。针对 push 系统设计， Short-lived jobs 可定时将 metrics push 到 Push gateway，再由 Prometheus server 从 Push gateway 上 pull metrics。这种方式主要用于服务层面的 metrics，对于机器层面的 metrics，需要使用 node exporter。
• Exporters：用于暴露已有的第三方服务的 metrics 给 Prometheus。
• Alertmanager：Prometheus 的报警组件，是与 Prometheus 组件相互分离的。Prometheus server 根据【告警规则】将 alerts 发送给 Alertmanager，Alertmanager 从 Prometheus server 接受到 alerts 后，进行去重、分组、降噪等处理，并将 alerts 通过路由发送到正确的接收器上，例如电子邮件、Slack、PaperDuty、HipChat、OpsGenie、WebHook 等。Alertmanager 还支持分组(Grouping)、抑制(Inhibition)、沉默(Silences)的机制。
• 一些其他工具的支持。

值得一提的是，大多数的 Prometheus 组件都是由 Go 语言编写的，这使得它们易于(作为二进制文件进行)构建和部署。

下图为 Prometheus 官网中的架构图：

由上图可见，Prometheus 的主要模块包块包括：Prometheus server、jobs/exporters、Pushgateway、PromQL、Alertmanager以及图形化管理界面(如：Grafana)。

其大概的工作流程：

• 1.Prometheus server 定期从配置好的 jobs/exporters 中拉 metrics，或者从 Pushgateway 中拉 metrics，或者从其他的 Prometheus server 中拉 metrics。
• 2.Prometheus server 在本地存储收集到的 metrics，并运行已定义好的 alert.rules(告警规则)，记录新的时间序列或向 Alertmanager 推送警报。
• 3.Alertmanager 根据配置文件，对接受到的警报进行处理，发出告警，并将这些告警路由到对应的接收器(电子邮件、PaperDuty 等)。
• 4.可视化图形界面(例如：Grafana)，将采集数据进行可视化。

三、Prometheus 的相关概念

下面介绍 Prometheus 的几个重要概念：Data model、Metric types、Jobs and instances。

Data model

Prometheus 几乎将所有的数据存储为时间序列，每个时间序列都由 metrics 名和一组键值对(也称为标签)唯一标识的，不同的标签代表不同的时间序列。除了存储时间序列外，Prometheus 还可以根据查询结果生成临时派生的时间序列。

• Metric Names(metric 名)：该名字应该具有语义，一般用于表示 metric 的功能(例如：http_requests_total，表示 http 请求的总数)。其中，metric 名由 ASCII 字符、数字、下划线以及冒号组成，并且不能以数字开头，需要符合正则表达式 [a-zA-Z_:][a-zA-Z0-9_:]*。
• Labels(标签)：使同一个时间序列有了不同维护的识别。例如：http_requests_total{method="Get"}，表示所有 http 请求中的 Get 请求的总数。当 method="Post" 时，则是一个新的 metric。标签中的键由 ASCII 字符、数字以及下划线组成，并且不能以数字开头，需要符合正则表达式 [a-zA-Z_][a-zA-Z0-9_]*。
• Samples(样本)：Samples 构成实际的时间序列数据，每个时间序列数据包含一个 float64 值和一个毫秒级的时间戳。
• Notation(格式)：形如：<metric name>{<label name>=<label value>, ...}，示例：api_http_requests_total{method="POST", handler="/messages"}。

Metric types

Prometheus 的 Client Libraries 提供了四种核心的 metric 类型：Counter、Gauge、Histogram、Summary。它们目前只在 Client Libraries 和 wire 协议中进行区分，Prometheus server 尚未使用类型信息，而是将所有的数据保存为无类型的时间序列。这个在将来或许会有所变化。

Prometheus 的 Client Libraries 提供的四种 metric 类型如下：

• Counter：一种累加的 metric，其值只能在重启时递增或重置为0。典型的应用如：请求的个数、结束的任务数、出现的错误数等。
  例如，查询 http_requests_total{method="get", job="Prometheus", handler="query"} 返回 8，10 秒后，再次查询，则返回 14。
  (注意：不要用 Counter 来标记可能会减少的值，比如正在运行的进程数量。)
• Gauge：一种常规的 metric，可以任意加减。典型的应用如：测量温度、当前内存的使用率；也用于“计数”，比如并发请求的数量。
  例如：go_goroutines{instance="172.17.0.2", job="Prometheus"} 返回值 147，10 秒后返回 124。
• Histogram：可理解为柱状图，提供 count 和 sum 全部值的功能，常用于跟踪事件发生的规模，典型应用如：请求耗时、响应大小。特别之处，可以对观察结果进行分组统计。
• Summary：与 Histogram 类似，提供 count 和 sum 全部值的功能，常用于跟踪事件发生的规模，典型应用如：请求耗时、响应大小。特别之处，提供百分位的功能，可按百分比划分跟踪的结果。

Jobs and instances

instance：一个单独 scrape 的目标，一般对应于一个进程。
job：一组同种类型的 instances(主要用于保证可扩展性和可靠性)。

当 scrape 目标时，Prometheus 会自动给这个 scrape 的时间序列附加一些标签(例如：instance、job)以便更好的分别。

示例说明

以实际的 metric 为例，对上述概念加以说明：

http_requests_total{code="2",handler="graph",instance="172.18.238.200:9090",job="prometheus"}
http_requests_total{code="2",handler="rules",instance="172.18.238.200:9090",job="prometheus"}
http_requests_total{code="2",handler="status",instance="172.18.238.200:9090",job="prometheus"}

可见，这三个 metric 的名字都一样，凭 handler 标签的值不同而被标识为不同的metrics。这类标签只会向上累加，属于 Counter 类型的 metric，且 metrics 中包含 instance 和 job 这两个标签。