📚 课程目录第2章 Prometheus基础回顾

2. Prometheus 基础回顾：核心概念与 PromQL 入门

在深入告警集成方案之前，必须牢固掌握 Prometheus 的核心概念与数据模型。本章将系统梳理 Metric、Label、Job、Instance 四大基石，解析时序数据模型，并快速入门 PromQL 查询语言，为后续服务目录资源健康检测打下坚实基础。

2.1 核心概念：Metric、Label、Job、Instance

Prometheus 通过 指标（Metric） 和 标签（Label） 描述监控目标的状态，通过 任务（Job） 和 实例（Instance） 定义采集拓扑。理解这四者的关系是使用 Prometheus 的第一步。

概念	定义	示例	作用
Metric	被监控的量化指标名称，描述“测量什么”	`http_requests_total`	定义监控项的类型与含义
Label	键值对，附加在 Metric 上描述“维度”	`method="GET"`, `status="200"`	实现多维数据模型，支持灵活聚合与过滤
Job	一组同类目标的逻辑分组，描述“采集任务”	`job="api-server"`	定义采集配置与目标发现范围
Instance	单个被监控目标的唯一标识，通常为 `host:port`	`instance="10.0.1.5:9090"`	定位具体采集端点，区分同一 Job 下的不同目标

关键理解： Metric 是“测量什么”，Label 是“从哪个维度测量”。同一个 Metric 可以携带不同 Label 组合，形成多条时间序列。Job 和 Instance 是 Prometheus 自动注入的标签，分别标识采集任务和目标地址。

2.2 数据模型：时间序列与多维结构

Prometheus 存储的核心是 时间序列（Time Series）。每条时间序列由 Metric Name 和一组 Label 唯一标识，每个时间点记录一个 Sample（值 + 时间戳）。

数据模型公式：

<metric_name>{<label_name>=<label_value>, ...}  =>  [ (timestamp1, value1), (timestamp2, value2), ... ]

例如，以下两条时间序列虽然 Metric 名称相同，但 Label 不同，代表不同的监控维度：

http_requests_total{job="api-server", instance="10.0.1.5:9090", method="GET", status="200"}
http_requests_total{job="api-server", instance="10.0.1.5:9090", method="POST", status="500"}

这种多维结构使得 Prometheus 能够在不增加 Metric 数量的前提下，通过 Label 组合实现丰富的查询与告警规则。

2.3 Metric 类型详解

Prometheus 客户端库提供四种核心 Metric 类型，每种类型适用于不同的监控场景：

类型	行为特征	典型用途	示例
Counter	只增不减（重启可重置）	请求计数、错误计数、任务完成数	`http_requests_total`
Gauge	可增可减，反映当前值	CPU 使用率、内存占用、连接数	`node_memory_MemAvailable_bytes`
Histogram	分桶统计，记录分布	请求延迟、响应大小分布	`http_request_duration_seconds`
Summary	分位数计算，类似 Histogram 但客户端计算	延迟分位数（0.5, 0.9, 0.99）	`http_request_duration_seconds_summary`

注意： Counter 类型在 PromQL 中通常配合 rate() 或 increase() 函数使用，直接查询原始值意义不大。Gauge 类型则可以直接用于告警阈值判断。

2.4 PromQL 入门：查询与聚合

PromQL（Prometheus Query Language）是 Prometheus 的查询语言，支持即时查询与范围查询。以下为告警场景中最常用的 PromQL 模式。

2.4.1 基础查询

# 查询所有 http_requests_total 时间序列
http_requests_total

# 带标签过滤
http_requests_total{job="api-server", method="GET"}

# 正则匹配标签值
http_requests_total{instance=~"10\\.0\\.1\\..*"}

# 范围查询：过去 5 分钟的数据
http_requests_total[5m]

2.4.2 常用函数

函数	作用	告警场景示例
`rate()`	计算 Counter 在指定时间窗口内的每秒平均增长率	`rate(http_requests_total[5m]) > 100`
`increase()`	计算 Counter 在指定时间窗口内的增量	`increase(http_requests_total[1h])`
`avg_over_time()`	计算 Gauge 在时间窗口内的平均值	`avg_over_time(node_cpu_seconds_total[5m])`
`max_over_time()`	计算 Gauge 在时间窗口内的最大值	`max_over_time(memory_usage[5m]) > 0.9`
`sum()`	按指定维度聚合求和	`sum by(instance) (rate(http_requests_total[5m]))`
`topk()`	返回前 K 个最大值	`topk(3, rate(http_requests_total[5m]))`

2.4.3 告警规则中的 PromQL 模式

以下为服务目录资源健康检测中常见的告警查询模式：

# 模式1：实例存活检测（基于 up 指标）
up{job="api-server"} == 0

# 模式2：错误率超过阈值
rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05

# 模式3：资源使用率过高
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.1

# 模式4：基于 Histogram 的延迟告警（P99 > 500ms）
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 0.5

最佳实践： 在告警规则中，始终使用 rate() 或 increase() 处理 Counter 类型指标，避免直接对原始 Counter 设置阈值。对于 Gauge 类型，建议配合 avg_over_time() 或 max_over_time() 进行平滑处理，减少抖动误报。

2.5 Job 与 Instance 的采集拓扑

在 Prometheus 采集架构中，Job 定义了一组采集配置（如目标发现方式、采集间隔、指标过滤），Instance 是每个具体的采集端点。Prometheus 会自动为每个采集到的样本添加 job 和 instance 标签。

2.6 本章小结

Metric + Label 构成 Prometheus 多维数据模型的核心，Label 是灵活聚合与过滤的关键。
Job 定义采集任务，Instance 标识具体目标，两者自动成为标签注入每条时间序列。
四种 Metric 类型（Counter、Gauge、Histogram、Summary）各有适用场景，告警规则中需正确选择。
PromQL 入门重点掌握 rate()、increase()、avg_over_time()、sum by() 等函数，它们是构建告警表达式的基础。