5月27日 17:39

Prometheus 工作原理是什么？从架构到数据流转全解析

Prometheus 是 CNCF 毕业的开源监控告警系统，以拉取（Pull）模式采集指标、TSDB 存储时序数据、PromQL 查询语言为核心，成为云原生可观测性的事实标准。本文从架构组件到数据流转，系统讲解其工作原理。

核心架构与组件

Prometheus 的架构围绕数据采集、存储、查询和告警四个环节展开，各组件协同完成从指标暴露到告警通知的完整链路。

Prometheus Server 是整个系统的核心，承担三个职责：通过 Scraper 定期从 Target 拉取指标数据，将数据写入本地 TSDB 存储，并对外提供 PromQL 查询接口。Server 本身是单节点部署，不依赖分布式存储，这也是它轻量高效的原因。

Exporter 是指标转换桥梁。各类第三方系统（MySQL、Redis、Node、Nginx 等）本身不暴露 Prometheus 格式的指标，Exporter 负责将它们的内部指标转换为标准格式，供 Server 拉取。每个 Exporter 暴露一个 /metrics HTTP 端点。

Pushgateway 解决短期任务的指标上报问题。批处理任务、Cron Job 等短生命周期进程可能在 Server 拉取前就已结束，Pushgateway 作为中间缓存接收这类任务主动推送的指标，再由 Server 从 Pushgateway 拉取。

Alertmanager 接收 Server 推送的告警，负责去重、分组、路由和静默，最终通过邮件、Slack、钉钉、Webhook 等方式通知。它支持抑制规则避免告警风暴，支持多路由将不同级别告警分发到不同渠道。

数据流转全链路

理解 Prometheus 工作原理的关键是弄清数据从产生到消费的完整链路。

第一步：指标暴露。 被监控服务自身或通过 Exporter 在 /metrics 端点暴露指标，每个指标由指标名称和一组键值对标签唯一标识，例如 http_requests_total{method="GET",path="/api"} 。

第二步：服务发现与拉取。 Prometheus Server 通过静态配置或服务发现机制（Kubernetes SD、Consul SD、DNS SRV 等）找到 Target 地址，按 scrape_interval（默认 15 秒）周期性发送 HTTP 请求拉取指标数据。服务发现让 Prometheus 能自动感知 Kubernetes 中 Pod 的增删，无需手动更新配置。

第三步：TSDB 存储与压缩。 拉取的样本数据以时间序列形式写入本地 TSDB。TSDB 采用列式存储，每个时间线独立存放，并通过压缩算法大幅降低存储占用。默认保留 15 天数据，可通过 --storage.tsdb.retention.time 调整。对于长期存储需求，可配置 Remote Write 将数据写入 Thanos、GreptimeDB 等远端存储。

第四步：PromQL 查询与聚合。 用户通过 PromQL 查询时序数据，支持即时查询和范围查询。常用操作包括速率计算 rate(http_requests_total[5m])、聚合 sum by (method)(rate(http_requests_total[5m]))、预测 predict_linear(node_filesystem_free[1h], 3600) 等。

第五步：规则评估与告警触发。 Server 根据 alert.rules 中定义的规则持续评估指标，当条件满足且持续 for 指定时长后，将告警推送到 Alertmanager。

Pull 模式的设计考量

Prometheus 选择 Pull 而非 Push 模式并非偶然。Pull 模式下 Server 掌握拉取节奏，避免被监控端突发流量冲垮；Server 可感知 Target 是否存活——拉取失败即意味着目标不可达；同时无需在被监控端配置 Server 地址，降低耦合。

对于必须 Push 的场景（短任务、Federation 跨集群），通过 Pushgateway 和 Remote Write 提供补充。

关键配置项解析

Prometheus 的主配置文件 prometheus.yml 控制着采集行为：

scrape_interval：全局拉取间隔，默认 15 秒，可按 Job 覆盖
evaluation_interval：规则评估间隔，默认 15 秒
scrape_timeout：单次拉取超时，默认 10 秒，不得超过 scrape_interval
metric_relabel_configs：拉取后对指标标签进行重写、过滤，减少无用时间线

合理的配置调优能显著降低 TSDB 的时间线基数，提升查询性能。

告警配置实战

一条完整的告警规则包含条件、持续时间和标签：

yaml
groups:
  - name: node-alerts
    rules:
      - alert: HighMemoryUsage
        expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) > 0.9
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "节点 {{ $labels.instance }} 内存使用率超过 90%"

for 字段确保瞬时波动不会触发告警，只有持续超阈值才正式触发。Alertmanager 收到后按路由规则分发。

版本演进与最新特性

Prometheus 3.0 于 2024 年底发布，是七年来最大版本更新。截至 2026 年 5 月，最新版本为 v3.12，LTS 版本为 v3.5.x。主要进展包括：

原生直方图（Native Histogram）在 v3.8 达到稳定状态，提供更高效的桶式聚合
Remote Write 2.0 协议提升远端写入性能和可靠性
UI 全面现代化，内置更直观的查询界面
OTLP 写入支持，可直接接收 OpenTelemetry 指标

这些演进使 Prometheus 在保持轻量架构的同时，逐步补齐长期存储和多协议兼容的短板。

适用场景与局限

Prometheus 在云原生容器监控、微服务可观测性、基础设施指标采集等场景下表现优异，尤其与 Kubernetes 的深度集成使其成为集群监控的首选。

需要注意的是，Prometheus 不适合需要 100% 精度的计费场景（采样间隔内可能丢失数据），原生 TSDB 的存储周期有限（长期存储需搭配远端方案），且不擅长日志和链路追踪的采集——这部分通常由 Loki 和 Tempo 补充，共同构成完整的可观测性体系。

标签：Prometheus