📚 课程目录第4章 Pure1与Pure Storage管理界面监控入门

4. Pure1与Pure Storage管理界面监控入门

Pure Storage 的性能监控体系由三个互补的入口构成：云端 SaaS 平台 Pure1、阵列本地的 Web 管理界面（GUI）以及命令行接口（CLI）。三者并非互相替代，而是分别覆盖“跨阵列长期趋势”“单阵列实时细节”“脚本化与深度诊断”三类场景。理解每个入口的数据来源、刷新机制和适用边界，是后续做瓶颈定位的前提。

三个入口的数据来源与定位

Pure1 的数据来自阵列主动上报的遥测（Telemetry）。阵列通过安全出站连接，将性能、容量、健康、配置等元数据周期性推送到 Pure1 云端，默认粒度约为分钟级聚合，并保留长期历史。这意味着 Pure1 看到的是“已经过云端聚合与建模”的数据，适合做跨阵列对比、容量与性能趋势预测、以及 Pure1 自带的 AI 分析（如 Workload Planner、VM Analytics）。它不提供秒级原始计数器，也不适合排查瞬时毛刺。

阵列 GUI 直接读取本地控制器上的实时统计，刷新粒度更细，通常可到秒级或数十秒级，并且能下钻到卷、主机、Pod、复制链路等对象。它是排查“此刻正在发生什么”的首选。CLI 则暴露了 GUI 未完全呈现的底层计数器与诊断命令，适合批量采集、脚本化监控和深度分析。

Pure1 遥测：看什么、怎么看

登录 Pure1 后，与性能监控最相关的是 Array 视图 和 Workload 视图。Array 视图给出每台阵列的 IOPS、带宽、延迟、容量使用率等汇总曲线，时间范围可拉到 90 天以上。Workload 视图则按卷或主机维度展示性能，适合回答“哪个业务在消耗最多 IOPS”。

Pure1 的一个关键能力是 基线对比：它会基于历史数据给出该阵列或该卷的“正常区间”，当实际曲线明显偏离基线时，即使绝对值不高，也值得关注。例如某卷平时写延迟稳定在 0.3 ms，某天开始持续在 1.2 ms，虽然 1.2 ms 对多数场景仍可接受，但偏离基线本身就是一个信号。

需要明确 Pure1 的局限：它不显示控制器 CPU、NVRAM 健康、FC 端口误码等底层指标，也不提供秒级突发视图。因此 Pure1 适合“发现异常”，不适合“定位根因”。

阵列 GUI：实时监控的主要工作台

通过阵列管理 IP 登录 GUI 后，Dashboard 页面提供整体健康概览，包括阵列状态、容量、性能摘要和最近告警。Analysis 页面是性能监控的核心，可按卷、主机、Pod、复制等维度查看 IOPS、带宽、延迟、队列深度等指标，并支持自定义时间窗口。

在 Analysis 中，一个实用的操作是：先选 Volumes 维度，按 Latency 排序，快速找出延迟最高的卷；再切到 Hosts 维度，确认是哪个主机在产生负载。如果延迟高但 IOPS 不高，通常指向队列等待或后端瓶颈；如果 IOPS 高且延迟同步上升，则更可能是负载本身超出了阵列当前的处理能力。

GUI 的 Alerts 面板会列出当前和历史告警，包括硬件、容量、复制链路等。性能类告警通常以“延迟超过阈值”“容量接近上限”等形式出现，点击可跳转到对应对象。

CLI 监控入口：脚本化与深度诊断

通过 SSH 登录阵列后，以下命令是性能监控的常用入口：

# 查看阵列整体性能摘要
purearray monitor --interval 5

# 查看指定卷的实时性能
purevol monitor my_volume --interval 5

# 查看主机性能
purehost monitor my_host --interval 5

# 导出性能数据为 CSV
purearray monitor --csv --interval 10 --count 60 > perf.csv

# 查看阵列容量与精简配置情况
purearray list --space

# 查看告警
purealert list

monitor 系列命令默认以表格形式持续刷新，适合在终端中观察实时变化；加上 --csv 后可重定向到文件，便于后续用脚本或表格工具分析。--interval 控制采样间隔，--count 控制采样次数。需要注意的是，过短的采样间隔（如 1 秒）在高负载阵列上可能增加额外开销，生产环境建议 5 秒以上。

基础报表解读：从数字到判断

无论从哪个入口获取数据，解读性能报表时都应关注以下几组关系：

IOPS 与延迟的联动：IOPS 上升时延迟适度上升是正常的；若 IOPS 未明显上升而延迟大幅上升，说明存在排队或后端瓶颈。
读/写比例：写比例高的负载对 NVRAM 和复制链路更敏感；读比例高的负载更依赖缓存命中率。
带宽与 IOPS 的比值：可反推平均 IO 大小。例如 10000 IOPS、400 MB/s，平均 IO 约 40 KB，属于偏大的块访问。
队列深度：队列深度持续偏高，说明前端请求积压，需要检查后端或主机侧多路径配置。
容量与性能的关系：容量使用率过高时，精简配置元数据和垃圾回收可能影响性能，通常建议保留一定余量。

在 GUI 的 Analysis 页面中，可以同时勾选多个卷进行对比。将同一主机的多个卷放在一起看，能快速判断是单卷热点还是主机整体负载问题。

三入口协同的排查示例

假设某业务反馈数据库响应变慢。第一步，在 GUI 的 Analysis 中按卷延迟排序，发现数据库卷 db_vol_01 的读延迟从 0.4 ms 升至 2.1 ms，IOPS 基本持平。第二步，用 CLI 执行 purevol monitor db_vol_01 --interval 5，观察队列深度和读/写比例，确认队列深度持续在 8 以上。第三步，在 Pure1 中查看该卷过去 30 天的延迟曲线，确认这是近期才出现的偏离，而非长期趋势。三步结合，可以初步判断问题出在阵列后端或主机侧多路径，而非业务量突增。