4. 数据采集与性能基线建立
性能监控真正产生价值，不是从“看到一条曲线”开始，而是从“知道这条曲线正常应该长什么样”开始。HPE Alletra 的性能数据采集与基线建立，核心任务就是三件事：把该采的数据按合适粒度采下来、把稳定运行期的数据沉淀成基线、再用基线去判断当前数据是否异常。缺少任何一环，监控都会退化成“看数字猜问题”。
一、采集策略：先决定采什么、多久采一次、保留多久
Alletra 的性能数据主要来自两个层面。一是阵列侧，通过 HPE Alletra Storage MP 的管理界面、REST API 或 HPE InfoSight/CloudPhysics 采集，可获取卷级、主机/主机组级、端口级、控制器节点级的 IOPS、带宽（MB/s）、平均读/写延迟、队列深度、缓存命中率、CPU 利用率等指标。二是主机侧，通过操作系统性能计数器或 HBA 统计采集，用于区分“是阵列慢还是主机侧慢”。
采集粒度不是越细越好。粒度越细，数据点越多，存储与查询成本越高，也越容易被瞬时抖动干扰。实践中可按用途分层：
- 实时排障层：5 秒～15 秒粒度，仅保留数小时到 1～2 天，用于抓取突发尖峰和短时拥塞。
- 日常监控层：1 分钟粒度，保留 30～90 天，用于观察日内与周内规律。
- 基线趋势层：5 分钟或 15 分钟聚合，保留 6～12 个月，用于容量与性能趋势、季度对比。
以某业务系统为例，若使用 1 分钟粒度采集 200 个卷的 6 个核心指标，一天约产生 200×6×1440 ≈ 172.8 万个数据点；若改为 5 秒粒度，则一天约 2073.6 万个点，量级相差 12 倍。因此在配置采集策略时，应优先保证“核心卷 + 核心指标”的高频采集，非关键对象降级为低频或按需采集。
二、基线建立：用稳定期数据定义“正常”
基线不是一条固定直线，而是一组带时间维度的正常范围。建立基线时，应选择业务稳定、无重大变更、无故障的连续时间段，通常建议至少覆盖 2～4 周，以包含工作日高峰、夜间批处理、周末低谷等典型形态。若业务有明显季节性，基线周期应相应拉长到 1～3 个月。
基线指标建议至少包含：
| 指标 | 基线形式 | 示例（假设值） |
|---|---|---|
| 卷读延迟 | 工作日 09:00–18:00 的 P95 | ≤ 1.8 ms |
| 卷写延迟 | 工作日 09:00–18:00 的 P95 | ≤ 2.5 ms |
| 卷 IOPS | 小时均值 ± 2σ | 12,000 ± 3,000 |
| 端口带宽 | 峰值利用率 | ≤ 65% |
| 控制器 CPU | 高峰均值 | ≤ 55% |
这里使用 P95 而不是平均值，是因为平均值会掩盖尾部延迟；而尾部延迟恰恰是业务感知最明显的部分。σ 为标准差，用于描述波动范围。若某小时 IOPS 超出均值 ±2σ，就值得关注；超出 ±3σ 则通常意味着异常。
三、异常识别：把当前数据放回基线中比较
异常识别的基本逻辑是“同时间、同对象、同指标”对比。例如，周一上午 10 点的读延迟，应与基线中“周一上午 10 点”的分布比较，而不是与凌晨 3 点比较。常见异常模式有三类：
- 水平偏移：指标整体抬高并持续，如读延迟从 1.5 ms 升到 4 ms 且不回落，常见于后端容量压力、缓存命中率下降或链路降级。
- 尖峰抖动：短时冲高后恢复，如写延迟瞬间到 20 ms，可能与快照、克隆、备份窗口或主机侧突发写入有关。
- 趋势漂移：指标缓慢上升，如端口带宽月均利用率从 40% 升到 60%，提示容量或链路需要提前规划。
下面这张图展示了从采集配置到基线判定再到异常分类的完整关系，重点体现“采集粒度分层—基线区间—异常判定”的对应关系。
四、落地建议与常见误区
第一，先定义业务关键卷，再配置采集。不要对所有卷平均用力，否则关键卷的高频数据会被淹没。第二，基线要定期复核。业务扩容、固件升级、新增主机、更换交换机后，原有基线可能失效，应重新选取稳定期数据更新基线。第三，异常判定要结合多指标。单看延迟升高可能是主机侧问题，需同时看阵列端口带宽、控制器 CPU、队列深度和主机 HBA 统计，才能定位瓶颈位置。
常见误区包括：用平均值代替 P95，导致尾部延迟被掩盖；用全天数据建基线，导致高峰与低谷混在一起；采集粒度太粗，错过短时尖峰；以及只采阵列不采主机，无法判断问题边界。把采集策略、基线区间和异常判定三者对应起来，才能让 Alletra 的性能监控从“看数”走向“诊断”。