1. 课程导入与全景认知

在开始学习任何监控工具之前，先要回答一个更根本的问题：为什么 Pure Storage 的性能监控与通用存储监控不一样？如果只是把 Pure FlashArray 当成一块"很快的盘"，用传统 SAN 的思路去看 IOPS、时延和带宽，往往会得出错误结论——因为 Pure 的性能瓶颈极少出现在介质层，而更多出现在主机侧、网络链路、卷配置、快照与复制策略、以及阵列内部资源调度这几个环节。本课程的目标，就是建立一套"从现象到根因"的诊断能力，而不是停留在"看仪表盘"的层面。

价值定位：从"看指标"到"定位根因"

Pure Storage 的监控体系有一个鲜明特点：它把大量底层复杂度封装在 Purity 操作系统内部，对外暴露的是简洁的 REST API、CLI（purecli / purearray）以及 Pure1 云端分析平台。这种封装带来便利，也带来一个副作用——当性能异常发生时，工程师容易只看到"阵列整体时延升高"这一层，却无法快速判断是某个卷的热点、某条链路的拥塞，还是某个主机的多路径配置问题。

因此，本课程的价值定位可以概括为三点：第一，建立分层诊断模型，把主机、网络、阵列、卷、快照/复制五个层面分开观察；第二，掌握 Pure 特有的指标语义，例如阵列级 latency 与卷级 usec 的区别、IOPS 与 bandwidth 在不同块大小下的换算关系；第三，形成可复现的排障路径，让每一次性能问题都能被记录、复现和验证。

核心概念：五个必须分清的对象

在进入具体工具之前，先厘清五个贯穿全课程的核心对象，它们决定了你后续看哪个指标、用哪个命令。

• Array（阵列）：物理控制器对，是性能数据的最高聚合层。阵列级指标反映整体负载，但会掩盖单卷热点。
• Volume（卷）：主机实际挂载的块设备，是性能归属的最小单位。卷级指标才是定位"谁在拖慢谁"的关键。
• Host / Host Group（主机/主机组）：发起 I/O 的客户端。主机侧的多路径、队列深度、文件系统行为都会影响最终观测到的时延。
• Snapshot / Protection Group（快照/保护组）：快照创建、复制传输会占用阵列资源，是常见的"隐性性能干扰源"。
• Pure1（云端分析）：提供跨阵列的历史趋势、容量与性能预测，适合做基线对比和容量规划，但不适合做秒级实时排障。

这五个对象之间是"聚合与归属"的关系：阵列级指标是卷级指标的汇总，卷级指标又受主机行为和快照策略影响。理解这层关系，才能避免"看到阵列忙就加盘"这类无效操作。

学习路径：四周从入门到独立排障

本课程共 30 章，建议按"认知—工具—指标—诊断—实战"的顺序推进。前 6 章建立全景认知与实验环境；第 7 至 14 章深入 CLI、REST API、Pure1 与第三方监控集成；第 15 至 22 章聚焦指标语义、基线建立与常见瓶颈模式；第 23 至 30 章进入真实故障场景的复盘与综合演练。

对于有经验的存储工程师，可以跳过部分工具介绍章节，但不建议跳过指标语义与基线建立部分——因为 Pure 的指标命名和传统存储差异较大，凭经验套用容易误判。

实验环境准备：最小可用拓扑

为了让后续章节的示例可复现，建议准备一套最小实验环境。若没有真实 FlashArray，可使用 Pure 官方提供的 Pure1 演示环境或 FlashArray//X 模拟器（部分功能受限）；若有真实设备，建议单独划分一个测试卷，避免影响生产。

实验环境的关键参数建议如下（示例值，非实测）：

环境就绪后，先用一条最简单的命令确认连通性：

purecli --host <array> --user pureuser array list
purecli --host <array> --user pureuser volume list --space

如果这两条命令能正常返回阵列和卷信息，说明 CLI 通道已打通，后续所有指标采集都可以在此基础上展开。

本节知识结构图

下图把本节的核心对象、诊断分层与学习路径整合为一张结构关系图，帮助你在进入后续章节前建立整体框架。

从本节出发的三个行动

在进入第 2 章之前，建议完成三件事：第一，确认你的实验环境能通过 CLI 或 REST API 访问阵列，并记录下阵列型号与 Purity 版本；第二，创建一个测试卷并记录其初始性能基线，哪怕只是空载状态下的时延数据；第三，明确你当前最关心的业务场景——是数据库高并发、虚拟化密集 I/O，还是备份窗口内的带宽争抢。这三个信息会决定你后续重点关注哪些指标和哪些章节。

性能诊断的本质不是记住更多命令，而是建立一套稳定的观察顺序和判断逻辑。当你能在 5 分钟内说清"问题出在哪一层、下一步该看哪个指标"，这门课的核心目标就达到了。