摘要：本文系统介绍了Prometheus监控系统的理论基础，涵盖监控核心概念、方法论、架构特点及数据模型。

主要内容包括：

1）监控系统的五大价值（预警、追溯、趋势分析等）和目标分层；

2）三大监控方法论（四大黄金指标、USE、RED）及其适用场景；

3）Prometheus的核心特点（多维数据模型、PromQL查询语言等）；

4）数据采集机制（Pull/Push模式）；

5）时间序列数据模型和标签系统。

文章可作为Prometheus入门学习的系统性参考资料，适用于面试准备和技术预研。

---

第一章 监控系统核心概念

1.1 什么是监控？

监控就是持续不间断地对系统或服务进行监视，以确保其一直处于正常运行状态。

1.2 监控的五大价值

价值	一句话说明	典型例子
事前预警	故障发生前发出告警，帮助提前规避问题	内存使用率超 80% 触发告警
事后追溯	利用监控数据快速分析故障原因	分析数据库查询延迟、CPU 负载等异常线索
趋势分析	根据指标变化预测未来问题	磁盘每天增 30GB，预测约 33 天后满载
对比分析	对比不同时段数据，分析系统在不同条件下的表现	正常工作日 vs 大促期间的系统负载对比
数据可视化	将指标以图形展示，直观了解系统状态	动态图表实时展示集群负载、内存、磁盘 I/O

1.3 监控的目标分层

业务监控   → 转换率、在线人数、QPS、交易量、订单量、注册量
应用监控   → NGINX / HAProxy / Tomcat（延迟、吞吐、错误率、饱和度）
组件监控   → RabbitMQ / Kafka / MySQL / Redis（请求延迟、吞吐、内存使用率）
系统监控   → CPU / 内存 / 网络 I/O / 磁盘 I/O（使用率、饱和度）
K8S 监控   → ETCD / ApiServer / Scheduler / Kubelet / CoreDNS

1.4 白盒监控 vs 黑盒监控

对比项	白盒监控	黑盒监控
关注点	问题的根本原因	问题的表面现象
手段	分析系统内部暴露的指标	通过 TCP/HTTP 探针模拟用户请求
典型场景	Redis info 命令查看内部状态	HTTP 探测返回 connection refused
告警示例	redis slave down	connection timeout
结论	两者相辅相成，结合使用才能全面了解系统状态

---

第二章 监控方法论

面试常问：这三种方法论分别用于什么场景？

2.1 四个黄金指标（Google）—— 适用于组件 / 应用监控

指标	含义	记忆关键词
延迟（Latency）	完成一次请求所需的时间（需区分成功/失败）	响应时间
流量（Traffic）	单位时间内处理的请求数（吞吐量）	QPS/TPS
错误（Errors）	请求错误的次数或错误率（如 100/10000 = 1%）	失败率
饱和度（Saturation）	资源被使用的程度（当前处理量 / 最大处理量）	使用率

2.2 USE 方法（Netflix）—— 适用于系统资源监控

指标	含义	示例
使用率（Utilization）	资源被使用的程度	CPU 60 秒内有 30 秒在工作 → 使用率 50%
饱和度（Saturation）	资源的排队等待长度（队列深度，不同于黄金指标）	CPU 平均负载持续高于核心数 → 饱和
错误（Errors）	资源事件错误计数	malloc() 失败次数；网卡丢包数

⚠️ 面试常问区分：USE 中的 Saturation 是队列深度；四大黄金指标中的 Saturation 是资源使用程度。

2.3 RED 方法（Weave Cloud）—— 适用于云原生 / 微服务监控

指标	含义	与黄金指标的区别
Rate（请求率）	每秒接收到的请求数	黄金指标"流量"是单位时间内处理的请求总量
Errors（错误数）	每秒失败的请求数	基本一致
Duration（处理时长）	处理每个请求所花费的时间	黄金指标"延迟"更关注系统整体响应时间

2.4 三种方法论总结对比

方法论	来源	适用场景	核心三字记忆
四大黄金指标	Google	服务/应用监控	延·流·错·饱
USE 方法	Netflix	系统资源监控	用·饱·错
RED 方法	Weave Cloud	云原生/微服务	率·错·时

---

第三章 Prometheus 介绍

3.1 Prometheus 是什么？

• 由 SoundCloud 使用 Go 语言开发的时序数据库（TSDB）
• 同时也是一款开源的监控系统
• 单靠 Prometheus 不够，需配合生态组件构建完整监控系统：

• • AlertManager — 告警管理
  • Grafana — 数据可视化
  • PushGateway — 短期任务指标推送中转

3.2 什么是时序数据？

按照固定时间周期对某个或某些指标进行反复测量，所得到的数据集合。

• Y 轴：数据值（指标值）
• X 轴：时间（测量时间点）

3.3 Prometheus 时序数据的三部分

组成部分	说明	示例
指标名称（MetricName）	被监控端提供，描述监控的内容	cpu_usage、memory_MemTotal
标签集（Labels）	键值对，用于区分不同数据源或实例	cpu_usage{type="web"}、cpu_usage{type="db"}
时序数据（时间戳 + 值）	按固定间隔采集的具体数据点	2023.03.30 10:00:01 → 50%

核心规则：每一个"指标名称 + 标签组合"形成一条独立的时间序列。每个具体数据点称为一个样本（Sample）。

---

第四章 Prometheus 的核心特点

4.1 多维数据模型

通过标签为同一指标添加不同维度，支持灵活查询与聚合。

# 同一指标，不同标签 → 不同时间序列
http_total{instance="ip1", path="/api", method="GET"}   500
http_total{instance="ip1", path="/api", method="POST"}  200
http_total{instance="ip2", path="/user", method="GET"}  1000

# PromQL 按 method 聚合
sum(http_total{path="/api"}) by (method)
# 结果：
{method="GET"}   500
{method="POST"}  200

4.2 强大的 PromQL

面试常问：为什么说 Prometheus 比 Zabbix 更灵活？

• Zabbix 需要在被监控端预先计算（如内存使用率），再传给服务器
• Prometheus 在中心服务器用 PromQL 直接计算：MemAvailable / MemTotal * 100

PromQL 能解决的典型问题：

• 预测 12 小时后磁盘空间占用
• 查询 CPU 占用前 5 位的服务
• 过去 1 分钟系统负载超过 CPU 核心数 2 倍的实例

4.3 高效的数据存储

• 使用专用时间序列数据库（TSDB）
• 每个数据点约占 3.5 字节（压缩算法）
• 官方数据：百万条时序数据，每 30 秒采集一次，保留 60 天，约 200GB

4.4 多种服务发现方式

发现方式	适用场景
静态配置	固定地址和端口
配置文件发现	配合 Ansible 等工具批量更新
Consul 注册中心	微服务架构
公有云 API 发现	监控 AWS RDS 等云资源
Kubernetes 发现	自动发现 Node/Pod/Endpoint/Ingress（最重要）

4.5 可扩展的架构

• 支持横向扩展：部署多个 Prometheus 实例
• 支持远程存储和 Prometheus 联邦（Federation）
• 适合大规模监控场景

---

第五章 Prometheus 数据采集

5.1 三种数据抓取机制（重点）

面试常问：Prometheus 和 Zabbix 数据采集有何不同？

Zabbix：被监控端需要安装专门的 Agent，由 Agent 主动将数据推送给服务器。

Prometheus：被监控端无需安装专门 Agent，只需通过 HTTP 协议暴露符合 Prometheus 格式的指标数据，Prometheus 主动拉取（Pull）。

三种机制详解：

机制	适用场景	工作方式
Instrumentation（直接采集）	应用原生支持 Prometheus 格式的指标（K8S、Haproxy、ETCD 等）	应用直接暴露 /metrics，Prometheus HTTP Pull
Exporter（导出器）	应用不原生支持 Prometheus 格式（MySQL、Redis 等）	Exporter 将原始数据"翻译"成 Prometheus 格式后暴露 /metrics
PushGateway（推送网关）	生命周期短暂、不方便被 Pull 的任务（如脚本、CronJob）	任务将数据主动 Push 给 PushGateway，Prometheus 再从 PushGateway Pull

应用程序/K8S/ETCD  ──────────────→ /metrics → Prometheus (HTTP Pull)
MySQL/Redis/Nginx  → Exporter → /metrics → Prometheus (HTTP Pull)
短暂脚本任务        → Push →  PushGateway → /metrics → Prometheus (HTTP Pull)

5.2 实例（Instance）与作业（Job）

概念	含义	标识方式
实例（Instance）	一个被监控的端点（进程）	host:port，如 10.0.0.51:3306
作业（Job）	功能相同的实例集合	例如所有 MySQL 实例归为 mysql Job

核心：Job 和 Instance 会自动附加到所有采集的时间序列上：

cpu_usage{job="node-exporter", instance="10.0.0.7"}  14.04
cpu_usage{job="node-exporter", instance="10.0.0.8"}  14.04

---

第六章 Prometheus 架构

6.1 五大核心组件

组件	职责
数据采集（Retrieval）	Pull 模式主动抓取 Exporter / Instrumentation 指标
数据存储（TSDB）	本地时序数据库，防止数据丢失
PromQL	内置查询语言，支持实时查询、聚合计算
告警规则 + AlertManager	规则在 Prometheus 端定义触发，AlertManager 负责去重、分组、发送（邮件/钉钉/微信）
数据可视化	内置简单 Web UI + 集成 Grafana 提供丰富图表

6.2 Prometheus 完整工作流程

服务发现（K8S/Consul/文件/静态）
       ↓
目标发现（Discover Targets）
       ↓
数据采集（Pull from Exporters / Instrumentation）
短暂任务（Push → PushGateway，再被 Pull）
       ↓
数据存储（TSDB / 远程存储）
       ↓
数据查询（PromQL）
       ↓
告警判断（Rules）→ AlertManager → 通知（邮件/微信/钉钉）
       ↓
数据展示（Web UI / Grafana）

---

第七章 Prometheus 数据模型

7.1 时间序列格式

<metric_name>{<label_name>=<label_value>, ...} @<timestamp> <value>

示例：

plant_height{type="sunflower", location="balcony"} @2024-06-01  30
plant_height{type="sunflower", location="balcony"} @2024-06-02  40
plant_height{type="sunflower", location="balcony"} @2024-06-03  50

7.2 指标名称（MetricName）

• 由小写字母、数字、下划线组成
• 例：cpu_usage = 15.05 表示当前 CPU 使用率 15.05%

7.3 标签（Labels）

• 以键值对形式存在，为指标添加详细信息（元数据）
• 用于区分不同节点、核心、实例等维度

# 区分不同节点
cpu_usage{instance="node01.chensiqi.net"}  15.05
cpu_usage{instance="node02.chensiqi.net"}  16.05

# 区分节点 + 核心
cpu_usage{instance="node01.chensiqi.net", core="0"}  7.535
cpu_usage{instance="node01.chensiqi.net", core="1"}  7.535