4. Metrics 采集与存储：Prometheus 架构、cAdvisor 指标、kube-state-metrics 指标，以及 Thanos/Cortex 的长期存储方案
在云原生成本分摊模型中，Metrics 是量化资源消耗、驱动分摊算法的基础数据源。本章聚焦于 Prometheus 生态的采集与存储体系，解析核心组件的数据特征，并对比长期存储方案，为后续的成本分摊关键路径追踪提供可靠的数据底座。
4.1 Prometheus 架构与数据采集链路
Prometheus 采用拉取（Pull）模式采集指标，其核心架构包含以下组件：
- Prometheus Server：负责指标抓取、存储与查询，内置时序数据库（TSDB）。
- Exporters：将应用或系统指标转换为 Prometheus 格式，如 cAdvisor（容器指标）、kube-state-metrics（K8s 对象状态指标）。
- Service Discovery：动态发现目标端点，Kubernetes 模式下自动关联 Pod、Service 等资源。
- Alertmanager：处理告警路由与去重，与成本异常检测联动。
关键路径提示： 成本分摊模型依赖的 Metrics 采集链路为：
cAdvisor → kubelet → Prometheus Server → 长期存储（Thanos/Cortex）。确保该链路无断点，是分摊数据准确性的前提。
4.2 cAdvisor 指标：容器资源消耗的原始度量
cAdvisor（Container Advisor）集成在 kubelet 中，负责采集每个 Pod 内容器的 CPU、内存、网络、磁盘等资源使用数据。这些指标是成本分摊模型中“容器级消耗”的直接来源。
| 指标类别 | 典型指标名 | 说明 | 成本分摊用途 |
|---|---|---|---|
| CPU 使用 | container_cpu_usage_seconds_total |
容器累计 CPU 时间（秒） | 计算 CPU 资源消耗占比 |
| 内存使用 | container_memory_working_set_bytes |
容器当前工作集内存（字节） | 计算内存资源消耗占比 |
| 网络流量 | container_network_receive_bytes_total |
容器网络接收字节累计 | 网络成本分摊依据 |
| 磁盘 I/O | container_fs_reads_bytes_total |
容器文件系统读取字节累计 | 存储成本分摊依据 |
最佳实践： 在成本分摊模型中，优先使用
container_cpu_usage_seconds_total 的 rate() 函数计算瞬时 CPU 使用率，而非直接使用原始累计值，以避免因 Pod 重启导致的数据跳变。
4.3 kube-state-metrics 指标：Kubernetes 对象状态的语义化数据
kube-state-metrics（KSM）从 Kubernetes API Server 监听资源对象状态，生成关于 Deployment、StatefulSet、Pod、Node 等对象的元数据指标。这些指标为成本分摊提供了“资源归属”和“调度上下文”。
- 资源请求与限制：
kube_pod_container_resource_requests、kube_pod_container_resource_limits，用于计算资源预留成本。 - Pod 状态：
kube_pod_status_phase，区分 Running、Pending、Succeeded 等状态，避免对非运行中 Pod 进行分摊。 - 工作负载标签：
kube_deployment_labels、kube_pod_labels，携带成本中心、项目、环境等标签，是分摊维度的关键来源。 - 节点容量：
kube_node_status_capacity、kube_node_status_allocatable，用于计算节点资源利用率与空闲成本。
注意： kube-state-metrics 不采集容器运行时资源使用数据，它只反映“期望状态”和“调度状态”。实际资源消耗必须结合 cAdvisor 指标。两者联合查询（Join）是成本分摊模型的核心操作。
4.4 Thanos / Cortex 长期存储方案
Prometheus 本地 TSDB 存在单点故障和存储容量限制，无法满足成本分摊模型对历史数据（通常需要 6-12 个月）的查询需求。Thanos 和 Cortex 是两种主流的长期存储方案，它们通过对象存储（如 S3、GCS）实现数据持久化与全局查询。
| 特性 | Thanos | Cortex |
|---|---|---|
| 架构模式 | Sidecar + Store Gateway + Compactor | 微服务组件（Distributor、Ingester、Querier） |
| 数据写入 | Sidecar 将 Prometheus TSDB 块上传至对象存储 | Distributor 接收 Remote Write 并分发至 Ingester |
| 全局查询 | Querier 合并本地与远程数据 | Querier 从 Ingester 和 Store Gateway 读取 |
| 多租户 | 需额外配置（通过标签隔离） | 原生支持多租户隔离 |
| 适用场景 | 已有 Prometheus 集群的扩展 | 大规模多团队共享的 Metrics 平台 |
4.5 样本抽检：保障成本分摊数据质量
在长期存储方案中，数据采样与压缩策略会影响成本分摊的精度。建议采用以下抽检机制：
- 原始数据保留窗口：Prometheus 本地保留 7-15 天的高精度数据（原始采样间隔 15s）。
- 降采样策略：Thanos Compactor 或 Cortex 的降采样组件将数据聚合为 5m、1h 分辨率，保留 6-12 个月。
- 抽检频率：每日对关键成本指标（如 CPU 使用率、内存使用量）进行随机抽检，对比原始数据与降采样数据的误差，确保分摊模型使用的聚合数据偏差在 5% 以内。
成本分摊关键路径： 在 Prometheus 中通过
kube_pod_labels 关联成本中心标签，再与 container_cpu_usage_seconds_total 进行 Join，即可生成“按标签聚合的容器资源消耗”视图，这是成本分摊模型的核心数据源。