Prometheus 数据模型与 PromQL 进阶

可视化演示

展示四种Metric类型时间序列特征、PromQL查询执行流程及指标类型性能对比的三模态交互动画。

时间序列模型

交通指挥中心的记录员每天会填一张固定格式的表：哪个路口、哪个方向、什么时刻、数值多少。这四个要素缺一不可，组合起来就是一条“时序记录”。在 Prometheus 里，这张表的“列名”叫指标名（metric name），“路口和方向”这些附加属性叫标签（labels），“时刻”叫时间戳，“数值”叫样本值。

Prometheus 中一条完整的时间序列可以用 指标名{标签组} 唯一标识。例如 http_requests_total{method="POST", status="200"} 表示“POST 请求中返回 200 的次数”。标签的意义在于给同一种指标切出多个维度：按接口切、按状态码切、按实例切，就像给每个路口加上了不同的路牌。

每个“样本”由三部分组成：时间戳（毫秒精度）、浮点数值、以及它们所属的序列标识。同一序列的样本按时间排成一条线，这就是“时间序列”名称的由来。

回到比喻：如果只用“车辆总数”而不写“哪个路口、哪个方向”，交通数据就是一团乱麻。Prometheus 的标签体系就是给每一条数据装上 GPS 坐标，让后续的查询可以精确到任何维度。

四种指标类型

指挥中心有不同的传感器：有的传感器测“累计通过车辆数”（只会越来越多，除非重置），有的测“当前拥堵指数”（随时可升可降），还有的测“通过时间的分布”（多少车在 1 秒内通过、多少在 2 秒内）。Prometheus 把监控指标也分成四种类型，它们决定了查询时该用什么姿势处理数据。

Counter（计数器）：只增不减，适合记录累计量，如请求总数、错误总数、CPU 总耗时。它的值是“从启动到现在的总数”，所以直接看数值没意义，要看增长速率。

Gauge（仪表盘）：可升可降，适合记录瞬时状态，如当前内存使用量、队列长度、在线人数。看 Gauge 直接看当前值即可。

Histogram（直方图）：把观测值分到多个桶里，统计每个桶的计数。它能算出 p50、p95、p99 等分位数，适合记录请求延迟这类分布型数据。

Summary（摘要）：在客户端直接算好分位数并上报，好处是查询端省计算，坏处是分位数跨实例无法聚合（因为两个 Summary 的分位数不能简单相加）。

选指标类型就像给传感器选功能：你要知道“一天总过多少车”就装累计计数器，要知道“现在堵不堵”就装瞬时仪表盘，要知道“通行时间分布”就装直方图。选错了工具，后面所有查询都会很别扭。

PromQL 基础语法

现在数据存好了，指挥中心要回答第一个问题：“昨天下午 3 点，浦东大道这个路口总共有多少辆车经过？” PromQL 的查询方式和我们查交通记录一样：先定位到具体的序列，再决定要看哪段时间的数据。

PromQL 最基本的查询是指标选择器：直接写指标名，如 http_requests_total，会返回所有匹配该指标的序列（每个标签组合算一条）。如果想缩小范围，就用花括号加条件：http_requests_total{method="POST", status=~"5.."}。= 是精确匹配，=~ 是正则匹配，!= 和 !~ 是反向匹配。

选择器后面跟不同后缀，会得到两种不同的数据结构：

即时向量（instant vector）：直接写 metric{...}，返回的是“当前这一瞬间”每个序列的最新样本值。它像一个快照，适合画当前状态。

区间向量（range vector）：写成 metric{...}[5m]，返回的是“过去 5 分钟内”每个序列的所有样本集合。它像一段录像，是 rate 这类函数必需的输入。

观察者的直觉是对的：想用“每 15 秒采一个点”的数据看趋势，必须把一段时间内的点打包成一个集合，这就是区间向量。有了录像带（区间向量），才能计算变化率；只有一张照片（即时向量），算不出任何变化。

聚合与函数

指挥中心的老大问：“全市所有路口的平均拥堵指数是多少？哪个路口最堵？过去 1 小时总共有多少辆车通过？” 这些都不能靠单条序列回答，需要一套“统计手术刀”对数据做加工——这就是 PromQL 的聚合操作符和函数。

rate 与 increase：rate(counter[5m]) 计算区间内 Counter 指标“每秒平均增量”，它自动处理了计数器重置问题（重启后归零再增长也能算对）。increase(counter[5m]) 则返回区间内的总增量。两者是分析 Counter 的核心工具。

sum by / sum without：sum(rate(http_requests_total[5m])) by (instance) 表示“把每个实例的增长率加起来，按实例分组”。这里的 by 相当于 SQL 里的 GROUP BY，without 相当于除某标签外的分组。

topk / bottomk：topk(5, sum(rate(...)) by (path)) 返回数值最大的 5 条序列，常用于“找出最热的接口 Top5”。

histogram_quantile：对 Histogram 桶数据计算分位数。histogram_quantile(0.95, sum(rate(duration_bucket[5m])) by (le)) 是求 p95 延迟的标答写法。

这就像指挥中心把所有路口的流量报表汇总：先算每个路口“每分钟增加几辆车”（rate），再把浦东的所有路口加起来（sum by 区域），最后排出最堵的前 5 个（topk）。层层递进，数据就从“枯燥的读数”变成了“有洞察的结论”。

典型监控场景

工具齐全了，指挥中心开始实战。三个最经典的监控场景，对应三套模板级查询，SRE 和可观测性工程师几乎天天都要写。

CPU 使用率：node_cpu_seconds_total 是 Counter，每种模式（user、system、idle）一个序列。空闲模式占比越低，说明 CPU 越忙。标准查询：

请求错误率：要算“最近 5 分钟 5xx 请求占总请求的比例”，用两个 rate 相除：

延迟分位数：配合 Histogram 桶数据，查询 p95 延迟：

这三个场景像指挥中心每天要回答的例行问题：“路网整体忙不忙”“有没有异常事故（错误）”“群众通行体验怎么样（延迟）”。模板背下来，改改指标名和标签就能套用到任何服务上。

性能优化

随着城市越来越大，传感器越来越多，指挥中心发现查询越来越慢。这就是 Prometheus 的“性能之痛”，主要有三个优化方向，也是生产环境中最常踩的坑。

控制标签基数：标签的组合数等于“基数”。如果一个标签有 100 种取值，两个标签就有 10,000 种组合，序列数量爆炸式增长（高基数）。比如把 user_id 这种高基数标签加进指标，每个用户都生成一条序列，存储和查询都会被拖垮。解决办法是把高基数信息从标签中移除，放到日志或单独的存储里。

录制规则（recording rules）：把常用且复杂的查询预计算，存成新指标。比如把 sum(rate(x[5m])) by (instance) 每小时算好存成 job:http_requests:rate5m，查询时直接读结果，不再实时计算。

合理选择时间窗口：[5m] 比 [1h] 快得多，因为要读的样本少；能用即时向量解决的就不用大区间向量。另外，长范围查询搭配大跨度 step 能显著降低计算量。

回到交通中心：如果给每辆车单独装一个传感器（高基数），系统必然崩溃；不如按路口、方向这种“可控维度”来装。常用报表提前印好（录制规则），临时查询才现算。这既是架构设计，也是查询习惯。

AI 应用场景

Python 演示

"""PromQL 查询模拟器：用 Python 模拟 Counter 时间序列与 rate 计算""" import mathimport random  class MockCounter:    """模拟一个 Counter 指标：只增不减，可能发生重置"""     def __init__(self, name, base=100, growth=2.0):        self.name = name        self.samples = []  # 每个元素是 (timestamp, value)        self._current = base        self._growth = growth        self._t = 0     def collect(self, seconds):        """采集 seconds 个采样点，间隔 15 秒"""        for _ in range(seconds):            self._t += 15            # 模拟真实环境：有增量、有噪声、偶尔重启归零            if random.random() < 0.05:                self._current = 0            self._current += self._growth + random.uniform(-0.5, 0.8)            self.samples.append((self._t, self._current))        return len(self.samples)  def rate(series, window_start, window_end):    """模拟 PromQL 的 rate 函数：返回窗口内每秒平均增量"""    in_window = [(t, v) for t, v in series if window_start <= t <= window_end]    if len(in_window) < 2:        return 0.0    first = in_window[0]    last = in_window[-1]    delta = last[1] - first[1]    # 处理计数器重置：如果出现负增量，把首值之前的累计量补回来    for i in range(1, len(in_window)):        if in_window[i][1] < in_window[i - 1][1]:            delta += in_window[i - 1][1]    dt = (last[0] - first[0]) / 1000.0    return max(delta / dt if dt > 0 else 0.0, 0.0)  def topk(series_dict, k):    """模拟 topk 聚合：按当前速率排序取前 k 名"""    return sorted(series_dict.items(), key=lambda kv: kv[1], reverse=True)[:k]  def main():    random.seed(42)    # 模拟三个服务的请求计数器    services = ["api", "worker", "gateway"]    counters = {}    for svc in services:        c = MockCounter("http_requests_total", base=random.randint(500, 1000))        c.collect(40)  # 40 个采样点，约 10 分钟        counters[svc] = c.samples     # 模拟过去 5 分钟的区间向量查询窗口    query_end = counters[services[0]][-1][0]    query_start = query_end - 300  # 5 分钟 = 300 秒     print("=== 各服务最近 5 分钟请求速率（rate）===")    rates = {}    for svc in services:        r = rate(counters[svc], query_start, query_end)        rates[svc] = r        print(f"  {svc}: {r:.2f} req/s")     print("\n=== topk(2, rate) 最热服务 ===")    for svc, r in topk(rates, 2):        print(f"  {svc}: {r:.2f} req/s")  if __name__ == "__main__":    main()

1. class MockCounter模拟一个只增不减、偶尔重置的 Counter 指标，采样间隔 15 秒
2. c.collect(40)采集 40 个样本点，对应 Prometheus 的拉起（scrape）行为
3. def rate(series, ...)实现 rate 函数：取窗口首尾差值除以时间跨度
4. if in_window[i][1] < in_window[i-1][1]检测计数器重置（值突然变小），把重置前的累计值补回增量
5. topk(series_dict, 2)按速率降序排序取前 2，等价于 PromQL 的 topk(2, sum(rate(...)) by (service))

常见误区

面试题