4. CAPI 数据采集机制：数据源类型、采集频率设计、数据质量保障策略
CAPI（Cluster Application Performance Insight）的容量评估精度，从根本上取决于数据采集机制的设计。一个健壮的采集机制需要回答三个核心问题：采什么（数据源）、多久采一次（频率）、采到的数据是否可信（质量保障）。本章从这三个维度展开，建立 CAPI 数据采集的工程化规范。
4.1 数据源类型与分类
CAPI 的数据源覆盖从硬件到业务的完整链路，按采集对象可分为以下四类：
| 数据源类别 | 典型指标 | 采集方式 | 数据粒度 |
|---|---|---|---|
| 基础设施层 | CPU 使用率、内存占用、磁盘 IOPS、网络吞吐 | Agent / SNMP / IPMI | 秒级 ~ 分钟级 |
| 容器与编排层 | Pod 资源请求/限制、节点可分配资源、集群调度失败率 | Kubernetes API / cAdvisor | 秒级 ~ 分钟级 |
| 中间件与数据库层 | 连接数、慢查询、队列深度、缓存命中率 | JMX / 内置 Exporter / 日志解析 | 分钟级 |
| 业务应用层 | QPS、RT（P50/P95/P99）、错误率、会话数 | APM Agent / 业务埋点 / 日志聚合 | 秒级 ~ 分钟级 |
实践建议：在容量规划初期，优先覆盖基础设施层和业务应用层的数据源。中间件层数据用于根因分析，可在第二阶段补充接入，避免采集管道过早过载。
4.2 采集频率设计原则
采集频率并非越高越好。过高的频率会消耗计算和存储资源，过低则无法捕捉容量突增。CAPI 采用分层频率策略：
- 高频采集（5~15 秒）：适用于 CPU、内存、网络 IO 等快速变化的资源指标，用于检测毛刺和瞬时过载。
- 中频采集（1~5 分钟）：适用于磁盘使用率、连接数、QPS 等趋势型指标，用于容量趋势建模。
- 低频采集（10~30 分钟）：适用于集群节点数、配额使用量、存储总量等慢变指标，用于长期容量水位跟踪。
频率设计公式：
采集间隔 ≤ (容量变化周期) / 10
例如：若业务高峰持续 30 分钟，则采集间隔不应超过 3 分钟，否则会丢失峰值形态。
采集间隔 ≤ (容量变化周期) / 10
例如：若业务高峰持续 30 分钟，则采集间隔不应超过 3 分钟，否则会丢失峰值形态。
4.3 数据质量保障策略
数据质量是容量评估的基石。CAPI 从采集、传输、存储三个环节建立保障策略：
4.3.1 采集端质量保障
- 心跳检测：每个采集 Agent 每 60 秒上报一次心跳，超过 3 个周期未收到则标记为“采集节点异常”。
- 数据完整性校验：每条采集记录携带 CRC32 校验码，接收端校验不通过则丢弃并触发重采。
- 超时熔断：单次采集超过 2 倍间隔时间仍未返回，则跳过本次采集，避免阻塞后续任务。
4.3.2 传输与存储质量保障
- 去重机制：基于 (采集节点 ID + 时间戳 + 指标名) 的三元组进行幂等去重，防止重复上报导致数据膨胀。
- 异常值过滤：采用 3σ 或 IQR 规则自动识别离群点，标记为“可疑”但不直接删除，供人工审核。
- 数据补全策略：对于缺失时间窗口，使用线性插值或前值填充（仅限连续缺失 ≤ 3 个点），超过阈值则标记为“数据空洞”。
4.4 数据质量度量指标
为量化数据质量，CAPI 定义了以下核心 KPI，用于持续监控采集健康度：
| 指标名称 | 定义 | 目标阈值 | 告警条件 |
|---|---|---|---|
| 采集覆盖率 | 实际采集节点数 / 应采集节点数 | ≥ 99.5% | < 98% 持续 5 分钟 |
| 数据完整率 | 无缺失时间窗口数 / 总时间窗口数 | ≥ 99.0% | < 95% 持续 10 分钟 |
| 异常值占比 | 标记为“可疑”的数据点数 / 总数据点数 | ≤ 1.0% | > 3% 持续 30 分钟 |
| 采集延迟 | 数据产生时间到写入存储的时间差（P99） | ≤ 30 秒 | > 60 秒持续 5 分钟 |
常见陷阱：不要仅依赖采集覆盖率一个指标。实践中经常出现“所有节点都在采集，但采集到的数据全是异常值”的情况。必须将异常值占比和采集延迟纳入日常巡检。