2. Prometheus 架构回顾：核心组件与数据流

在深入成本分摊与归因之前，必须先厘清 Prometheus 的架构。只有理解数据从产生、采集、存储到告警的完整链路，才能精准定位成本归属。Prometheus 采用 拉取（Pull） 为主的架构，辅以 推送（Push） 机制，整体由五个核心组件构成。

2.1 核心组件一览

2.2 组件详解与数据流

2.2.1 Prometheus Server

Prometheus Server 是整个系统的 大脑。它负责：

• 服务发现与目标管理：通过 Kubernetes、Consul、文件等方式动态发现采集目标。
• 指标拉取（Scrape）：按配置的时间间隔（如 15s）向 Exporter 或 Pushgateway 发起 HTTP 请求。
• 数据写入 TSDB：将拉取到的样本数据写入本地磁盘。
• 查询与聚合：对外提供 PromQL 查询接口，支持实时查询与历史回溯。

2.2.2 TSDB（时序数据库）

TSDB 是 Prometheus 的 存储核心，负责高效写入和压缩时序数据。其关键特性包括：

• Block 结构：数据按时间窗口（默认 2 小时）切分为不可变的 Block，每个 Block 包含 index、chunks、meta.json 等文件。
• 压缩与合并：后台定期对 Block 进行压缩（Compaction），减少文件数量，提升查询效率。
• WAL（Write-Ahead Log）：先写日志再落盘，保证数据可靠性。

2.2.3 Exporter

Exporter 是 数据源头，负责将目标系统的内部状态转换为 Prometheus 可识别的指标格式。常见的 Exporter 包括：

• Node Exporter：主机级指标（CPU、内存、磁盘、网络）。
• cAdvisor：容器级指标（Kubernetes 容器资源使用）。
• Blackbox Exporter：网络探测指标（HTTP、TCP、ICMP）。
• Kube-State-Metrics：Kubernetes 对象状态指标（Deployment、Pod、Service）。

2.2.4 Pushgateway

Pushgateway 用于采集 短生命周期任务（如批处理作业、CronJob）的指标。这些任务无法等待 Prometheus 来拉取，因此主动将指标推送到 Pushgateway，再由 Prometheus 统一拉取。

• 适用场景：CI/CD 流水线、数据 ETL 任务、一次性脚本。
• 成本陷阱：Pushgateway 中的指标不会自动过期，容易造成 指标残留，导致存储成本虚高。

2.2.5 Alertmanager

Alertmanager 负责处理 Prometheus Server 发出的告警，执行 去重、分组、静默、抑制 和 通知 等操作。虽然它不直接产生指标，但告警的频繁触发会间接增加 Prometheus Server 的查询负载和通知渠道的成本（如 PagerDuty、Slack 的 API 调用费用）。

2.3 数据流全景

下图展示了 Prometheus 从指标采集到告警通知的完整数据流，以及每个环节的成本归属点。

2.4 数据流关键路径

1. 指标暴露：Exporter 或 Pushgateway 在 /metrics 端点暴露指标数据。
2. 服务发现与拉取：Prometheus Server 根据配置发现目标，发起 HTTP GET 请求拉取指标。
3. 数据写入：Server 将拉取到的样本写入 TSDB 的 WAL，随后异步落盘为 Block。
4. 告警评估：Server 根据 rules 配置定期评估告警规则，触发时发送到 Alertmanager。
5. 告警通知：Alertmanager 对告警进行分组、去重后，通过配置的接收器发送通知。
6. 查询与展示：用户通过 PromQL 查询 TSDB 数据，Grafana 等可视化工具展示结果。

2.5 成本归因核心原则