构建Prometheus指标采集平台实践

可视化演示

核心架构理念

小李接手了一座大型智慧社区。社区里几十栋楼、上百套设备，第一件事是定规矩：设备状态怎么上报？有人提议给每家装部电话，让住户主动打来报数——可这样物业会接到成百上千通电话，谁没打、谁家电话坏了，你根本说不清。小李坚持另一套方案：巡检员按固定路线、固定周期，亲自上门查表。查表时发现哪家门敲不开，立刻就知道出了问题。这就是 Prometheus 的 pull 模型：采集器不等待上报，而是主动发起 HTTP 请求，到目标暴露的 /metrics 端点取数。

这套“上门抄表”的思路贯穿整个平台设计。每个被采集的对象（目标）都是一个“住户”，通过 Exporter 把内部状态翻译成标准指标。Prometheus 的指标模型由三部分组成：指标名、标签和样本值。指标名说明“这是什么”（比如总请求数），标签说明“这是哪一类的”（哪个接口、哪个服务），样本值就是当时的读数。

按照数值性质，指标分为四类：Counter 只增不减，适合累计请求数；Gauge 可增可减，适合当前温度、内存水位；Histogram 记录数值分布区间；Summary 记录分位数。一条完整的时间序列长这样：

账本条目一旦有了“哪栋楼、哪根水管、什么时间”这些标签，物业想统计任意切片——比如“所有 GET 请求”“所有 5 开头错误”——只需按标签过滤后聚合，不用改任何埋点。选对命名和标签设计，是整套巡检体系的第一块地基。

Exporter选型

确定“上门抄表”后，小李发现每台设备长着不同的“表盘”——MySQL 的内部计数器、Redis 的内存统计、Nginx 的连接数，格式五花八门。Prometheus 无法直接读懂每家设备，需要一种“翻译电表”：Exporter。它把软件内部状态翻译成统一格式的指标，暴露在一个 /metrics 端点，供巡检员读取。

选择 Exporter 有三条路。官方 Exporter 是国标电表，node_exporter、mysqld_exporter、redis_exporter 等由 Prometheus 社区维护，质量最稳；第三方 Exporter 是经过认证的仪表，kube-state-metrics 等由云原生生态维护；自研 Exporter 是定制的专用表，用官方 SDK 在业务代码里暴露自定义指标。选型时先问三个问题：维护方是否活跃、暴露的指标基数有多大、每次抓取的开销是否可控。

电表通常只记录累计度数，但物业真正关心的是“最近一小时耗电增速”。Prometheus 通过 rate 函数从 Counter 类指标计算速率：

选好表、读好数，还要留意“表本身别出错”——抓取超时、重试、把用户 ID 放进标签，都会撑爆账本。如同物业不会给每台设备都装最贵的传感器，合理控制指标基数，才能让整套系统轻盈可扩展。

服务发现机制

小区住户流动性大，三号楼搬来一家创业公司，五号楼撤走一个机房。如果物业手里的住户名单靠手写，巡检员就会敲错门、漏抄表。幸运的是，在云原生社区里，Kubernetes 的 API Server 就是那本实时更新的“住户登记册”——每个 Pod、Service、Endpoints 的起落都会自动登记。

Prometheus 通过服务发现机制订阅这份登记册，支持多种来源：最常遇见的 kubernetes_sd_configs 直接对接 API Server；虚拟机或物理机场景常用 file_sd_configs 读取文件；云厂商可用 ec2_sd_configs。服务发现产出的是目标列表，还需要 relabeling（标签重写）来处理：筛选掉不该采集的命名空间、把服务名映射成统一标签。经过筛选后，真正纳入采集的目标数是：

服务发现的意义在于“人走不误事”：Pod 扩容到 20 个副本，登记册自动更新，巡检员下一轮抄表就多跑 20 家；Pod 崩溃，目标消失，Prometheus 立刻标记下线。物业团队从此告别手工维护 target 清单，这是平台能横向扩展的关键前提。

数据存储方案

巡检员每天抄回数百条读数，总得有个地方归档。Prometheus 自带的 TSDB（时间序列数据库）就是物业的账本档案室。数据按时间戳组织，每两小时形成一个 block 区块——好比账本每隔两天装订成一册；写入前先落 WAL 预写日志，如同会计先在草稿本上记账、再誊抄到正式账本，防止断电丢账。

档案室面积有限，账本不能无限堆积。TSDB 默认保留 15 天，到期区块自动清理。设计容量时，磁盘空间按四要素估算：

生产环境还要考虑持久化——为 Prometheus 挂载持久卷，避免 Pod 重建导致账本丢失；本地盘和云盘按吞吐量选择。当序列数超过几十万时，单机 TSDB 会逼近性能上限，这时就该考虑后面的联邦与长期存储方案。理解“本地存储是有限资源”这个前提，才能顺理成章地引入档案馆。

长期存储方案

年底物业要出一份年度用电报告，需要一年前的逐时数据，可小区账本只留了 15 天。怎么办？小李决定把老账本定期“扫描归档”到城市档案馆——归档后把原件清理掉，小区只留近期账本，查询历史时再去档案馆调阅。这套体系在 Prometheus 世界里的名字叫 Thanos。

Thanos 由几个核心组件组成：Sidecar 跟随每个 Prometheus 实例，把本地 block 上传到对象存储（S3、MinIO、OSS 等）；Querier 作为统一查询入口，同时读取本地和归档数据，对外表现成一个超大 Prometheus。为了压缩成本、加快查询，归档数据会做降采样——把高精度原始点合并成低精度摘要：

除了 Thanos，Cortex 是另一条路线：多租户、分布式、兼容 PromQL。无论哪条路，核心设计理念一致：本地存储管“热”数据，对象存储管“冷”数据，查询层透明路由。城市档案馆让物业不必扩建自家档案室，还让历史数据“要啥有啥”——这就是长期存储的价值。

联邦集群高可用

社区版图越来越大，分成东区、西区、南区十几个分区，每个分区都有自己的物业中心。总部领导不关心某个机房的细节，但想看全社区的总览。解决方案是层级汇报：每个分区 Prometheus 先把本区数据抓齐，总部通过联邦机制从分区汇总。

联邦抓取利用 /federate 端点，顶层 Prometheus 按 match[] 参数选择需要汇总的指标，类似总部只要求分区上报“大类指标”而不是全部细账。同时，高可用依赖双副本：每个分区部署两个完全相同的 Prometheus 实例，抓同一批目标。查询端（如 Thanos Querier）对两个副本的结果做去重，告警端 Alertmanager 做分组与抑制，避免同一问题触发两次告警。汇总出的在线目标总数可以用公式表达：

双人轮班加总部汇总，物业体系既不怕单个巡检员请假，也能在总部一张屏上纵览全局。联邦不是越多层越好——层级过深会增加查询延迟，一般控制在两层以内，与组织架构一样保持扁平。

云原生生态整合

社区里的电梯、供水、中央空调由不同厂商维护，但物业不需要自己研究每台设备的内部结构——厂商都装了标准传感器。K8s 集群同样自带三个“标准传感器”：node_exporter 采集主机层的 CPU、内存、磁盘、网络；cadvisor 嵌在 Kubelet 中采集每个容器的资源使用；kube-state-metrics 从 API Server 读取 Deployment、ReplicaSet、Pod 的期望与实况。三者叠加，形成“机器—容器—工作负载”三层观测。

实际部署常借助 kube-prometheus-stack（Prometheus Operator 全家桶），一键把 Prometheus、三大 Exporter、Grafana、告警规则装进集群。通过 ServiceMonitor 声明“哪些服务要被抓取”，Prometheus 自动更新抓取配置，无需手工改文件。容器 CPU 利用率是最常看的指标之一：

公共传感器装好，物业的“公共设施巡检盘”就齐了。但在 AI 时代，社区里还有一类特殊设备不在标准传感器覆盖范围内——算力大厦里的 GPU，这正是下一节的主角。

AI场景监控

社区数据中心新装了几百张 GPU 卡，每张价值数万，利用率直接决定运营成本。普通电表（node_exporter）只能看到整机功耗，看不到 GPU 内部的算力引擎是否空转。NVIDIA 提供了专用传感器 DCGM Exporter，暴露 SM 利用率、显存占用、温度、功耗等细粒度指标。

除了硬件，AI 推理服务本身也需要“出餐监控”：请求量（QPS）反映客流量，P99 延迟反映最慢的出餐节奏，批处理大小与队列长度反映厨房拥堵情况。这些指标通过在推理服务中埋点暴露，常用的延迟指标是直方图（Histogram），Prometheus 用 histogram_quantile 估算分位数：

有了这些指标，弹性伸缩才有依据：GPU 利用率长期低于 30% 就触发缩容或合并批处理；推理 P99 超过 200ms 就触发扩容或切流。告警联动 K8s HPA 与 Cluster Autoscaler，形成“感知—决策—执行”闭环。至此，从普通住宅到算力大厦，从公共设施到 AI 服务，整套巡检体系覆盖了社区每一个角落。

AI 应用场景

Python 演示

import timeimport randomfrom collections import deque  class FakeEndpoint:    """模拟一个暴露指标的 exporter, 每次抓取读数小幅增长"""     def __init__(self, name, base):        self.name = name        self.value = base     def scrape(self):        """模拟一次抓取, 返回 (指标名, 标签, 值, 时间戳)"""        self.value += random.uniform(0.1, 1.0)        return (self.name, {"job": "demo"}, round(self.value, 2), time.time())  class MiniPrometheus:    """简化版 Prometheus: 周期拉取目标并保存时间序列"""     def __init__(self, interval=1):        self.interval = interval        self.endpoints = []        self.series = {}        self.series_max = 60     def register(self, endpoint):        self.endpoints.append(endpoint)     def scrape_once(self):        """对每个目标执行一次拉取, 类似巡检员上门抄表"""        for ep in self.endpoints:            name, labels, value, ts = ep.scrape()            key = (name, frozenset(labels.items()))            bucket = self.series.setdefault(key, deque())            bucket.append((ts, value))            if len(bucket) > self.series_max:                bucket.popleft()        print("[%s] 完成一轮拉取, 序列数=%d" % (            time.strftime("%H:%M:%S"), len(self.series)))     def run(self, rounds):        for _ in range(rounds):            self.scrape_once()            time.sleep(self.interval)     def latest(self):        return {k[0]: v[-1][1] for k, v in self.series.items() if v}  if __name__ == "__main__":    prom = MiniPrometheus(interval=1)    prom.register(FakeEndpoint("node_cpu_seconds", 12))    prom.register(FakeEndpoint("http_requests_total", 35))    prom.run(5)    print("最新读数:", prom.latest())

1. key = (name, frozenset(labels.items()))把指标名与标签组转换成不可变键，确保每个“账本页”唯一。
2. bucket = self.series.setdefault(key, deque())为每类指标维护一个队列，相当于给每类电表单独开一页账本。
3. bucket.popleft()队列超过 60 个点就丢掉最旧的，模拟 retention 保留策略。
4. ep.scrape()采集器主动调用目标暴露的方法，而不是等目标上报，这正是 pull 模型的核心动作。
5. time.sleep(self.interval)两次抄表之间的间隔，对应 Prometheus 的 scrape_interval。
6. prom.register(FakeEndpoint("http_requests_total", 35))把目标注册进采集列表，对应服务发现中的目标注册。

常见误区

面试题