4. 成本数据采集源：Prometheus Metrics、kube-state-metrics、cAdvisor、云厂商账单API的数据采集路径与传输开销

在云原生成本分摊模型中，数据采集是成本计算的起点。不同的采集源在数据精度、采集频率、网络带宽消耗以及计算资源开销上存在显著差异。本章将深入分析四种核心采集源的数据路径与传输开销，帮助你在设计成本分摊系统时做出合理的采集策略选择。

4.1 四种采集源的核心特征对比

4.2 数据采集路径详解

4.2.1 Prometheus Metrics 采集路径

Prometheus 采用 Pull 模型主动从目标端点抓取指标。在成本分摊场景中，通常通过 prometheus.yml 配置 scrape_configs 来定义采集目标。

scrape_configs:
  - job_name: 'cost-metrics'
    scrape_interval: 30s
    static_configs:
      - targets: ['node-exporter:9100', 'app-metrics:8080']
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance

传输路径： 目标 Exporter → HTTP GET → Prometheus Server → TSDB 存储 → 成本分摊引擎查询。

开销分析：

• 网络开销： 每次抓取约 2-5 KB 的 HTTP 响应体，30s 间隔下每小时约 240-600 KB/目标。
• 计算开销： Prometheus Server 需要对指标进行解析、标签索引和压缩，CPU 开销约为 0.1-0.3 核/千个活跃序列。
• 存储开销： 原始数据采用 TSDB 块压缩，压缩比约 10:1，1 小时 200 MB 原始数据约占用 20 MB 磁盘。

4.2.2 kube-state-metrics 采集路径

kube-state-metrics (KSM) 监听 Kubernetes API Server，生成关于资源对象状态的指标。它不直接采集容器运行时数据，而是反映集群的“期望状态”。

# 典型 KSM 指标示例
kube_pod_info{namespace="production", pod="nginx-7d8b9c6f8c-abcde"}
kube_pod_container_resource_requests{namespace="production", pod="nginx-7d8b9c6f8c-abcde", resource="cpu", unit="core"} 0.5
kube_node_status_capacity{node="worker-1", resource="memory"} 16384

传输路径： KSM Pod → Kubernetes API Server Watch → 指标聚合 → HTTP 端点 → Prometheus 抓取。

开销分析：

• API Server 压力： KSM 对 API Server 的 List/Watch 请求频率约为每 30s 一次，在 5000 Pod 规模的集群中，API Server 额外负载增加约 5-8%。
• 指标基数： 每个 Pod 会产生约 20-30 个时间序列，1000 个 Pod 对应 2-3 万个序列，内存占用约 200-300 MB。
• 传输压缩： 建议启用 Prometheus 的 snappy 压缩，可将传输体积减少 60-70%。

4.2.3 cAdvisor 采集路径

cAdvisor 集成在 kubelet 中，默认暴露容器资源使用指标。它是成本分摊中最细粒度的数据源，但也是开销最大的采集源。

# cAdvisor 暴露的容器 CPU 指标
container_cpu_usage_seconds_total{container="nginx", pod="nginx-7d8b9c6f8c-abcde", namespace="production"} 12345.67
container_memory_working_set_bytes{container="nginx", pod="nginx-7d8b9c6f8c-abcde", namespace="production"} 52428800

传输路径： kubelet cAdvisor → /metrics/cadvisor 端点 → Prometheus 抓取 → 成本引擎聚合。

开销分析：

• 数据爆炸： 每个容器每 15s 产生约 50-80 个时间序列，100 个节点 × 200 容器/节点 = 20000 容器，每小时产生约 1.5-2.5 亿个数据点。
• 网络带宽： 单节点 cAdvisor 端点每次抓取约 50-100 KB，30s 间隔下每小时约 6-12 MB/节点，100 节点集群每小时约 600-1200 MB。
• 存储成本： 建议对 cAdvisor 指标进行降采样（downsampling），保留原始数据 7 天，聚合数据 30 天，可减少 80% 的存储开销。

4.2.4 云厂商账单API 采集路径

云厂商账单 API（如 AWS Cost Explorer、Azure Cost Management、GCP Billing API）提供实际的货币成本数据。这是成本分摊的“锚点”，用于校准基于资源使用率的估算成本。

# 示例：AWS Cost Explorer API 请求
aws ce get-cost-and-usage \
    --time-period Start=2025-01-01,End=2025-01-02 \
    --granularity HOURLY \
    --metrics "BlendedCost" "UsageQuantity" \
    --group-by Type=TAG,Key=kubernetes-cluster

传输路径： 成本引擎 → HTTPS 请求 → 云厂商 API 网关 → 计费系统 → JSON/CSV 响应 → 成本引擎解析。

开销分析：

• API 调用成本： 云厂商对账单 API 调用通常有免费额度（如 AWS 每月 100 万次请求），超出后按 $0.01/千次计费。
• 数据延迟： 账单数据通常有 6-24 小时的延迟，不适合实时成本分摊，建议用于日/月级别的对账。
• 传输体积： 每次拉取 1 天的详细账单（含标签）约 1-5 MB，压缩后约 200-800 KB。
• 频率建议： 每小时拉取一次即可满足大多数场景，避免频繁调用导致 API 限流和额外费用。

4.3 传输开销对比与优化策略

4.4 采集路径架构总览

下图展示了四种采集源在云原生成本分摊系统中的完整数据路径，以及各环节的传输开销关键点。

4.5 实际案例：100节点集群的采集开销估算

假设一个 100 节点、2000 Pod 的生产集群，采用 30s 采集间隔，各采集源的月传输开销估算如下：

4.6 采集策略选择矩阵

根据不同的成本分摊精度需求，推荐以下采集策略组合：