磁盘慢了，应用就慢了——为什么要关注 await
实际操作要点
关于Prometheus Node，最值得先弄清楚的是配置边界和排错顺序。当你发现网站加载变慢、数据库查询超时、或者文件传输卡顿，第一个怀疑对象往往不是 CPU 或内存，而是磁盘。磁盘 I/O 是 Linux 服务器中最容易成为瓶颈的环节，而 await 正是衡量磁盘响应速度最直观的指标。
简单说，await 是磁盘完成一次 I/O 请求所需的平均时间（毫秒）。它包含了请求在队列中等待的时间以及真正读写数据的时间。如果 await 很高，说明磁盘很“忙”或者本身性能无法满足当前负载，应用层的读写操作就会被阻塞，进而拖慢整个系统的响应。
但 await 不能被孤立地看。一个 30ms 的 await 在 SATA 机械盘上可能还算正常，在 NVMe SSD 上就说明出问题了。因此，我们需要持续监控 await 的变化趋势，而不是只看一次绝对值。
用什么工具监控 await？Prometheus + Node Exporter
我的处理经验
Prometheus 是目前最流行的开源监控系统，它通过拉取目标端点上的指标数据来工作。Node Exporter 是 Prometheus 的官方组件之一，专门用于采集 Linux 主机的系统层指标，包括 CPU、内存、网络、磁盘等。
磁盘 I/O 相关的指标中，Node Exporter 提供了 node_disk_io_time_seconds_total（磁盘忙碌时间）、node_disk_reads_completed_total（读完成次数）、node_disk_writes_completed_total（写完成次数）等。但 await 不是直接暴露的，需要我们自己通过公式计算。
好在 PromQL 可以轻松完成这件事：
rate(node_disk_io_time_seconds_total[1m]) * 1000 / rate(node_disk_reads_completed_total + node_disk_writes_completed_total[1m])这个公式的含义是：取最近 1 分钟内磁盘忙碌时间的增量（转为毫秒），除以 I/O 完成次数的增量，得到平均每次 I/O 的耗时，也就是 await。
分步搭建监控环境（面向小白的操作指南）——Prometheus Node
1. 安装 Node Exporter
所有操作在 Linux 服务器上执行（以 Ubuntu 20.04 为例）。
- 下载最新版本：
wget https://github.com/prometheus/node_exporter/releases/latest/download/node_exporter-1.7.0.linux-amd64.tar.gz - 解压：
tar xvf node_exporter-*.tar.gz - 移动到 /usr/local/bin：
sudo mv node_exporter-*/node_exporter /usr/local/bin/ - 创建 systemd 服务文件
/etc/systemd/system/node_exporter.service，内容如下：
[Unit]
Description=Node Exporter
After=network.target
[Service]
ExecStart=/usr/local/bin/node_exporter
Restart=always
[Install]
WantedBy=multi-user.target- 启动并设置开机自启：
sudo systemctl enable --now node_exporter - 验证：访问
http://你的服务器IP:9100/metrics，能看到大量以node_开头的指标。
2. 安装 Prometheus
可以用官方提供的二进制包，也可以用 Docker。这里用二进制方式演示快速部署。
- 从官网下载：
wget https://github.com/prometheus/prometheus/releases/download/v2.52.0/prometheus-2.52.0.linux-amd64.tar.gz - 解压：
tar xvf prometheus-*.tar.gz - 编辑配置文件
prometheus.yml，在scrape_configs下添加 job：
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['localhost:9100']如果有多个服务器，可以把 localhost 替换成对应 IP，或者使用文件发现、consul 发现等方式。
- 运行 Prometheus：
./prometheus --config.file=prometheus.yml - 访问
http://服务器IP:9090，在输入框中输入up，如果看到node对应的值为 1，表示抓取成功。
3. 安装 Grafana 并配置面板
Grafana 是可视化工具，推荐用 Docker 快速安装（前提是你已经安装了 Docker）。
docker run -d --name=grafana -p 3000:3000 grafana/grafana访问 http://服务器IP:3000，默认账号密码均为 admin，第一次登录会要求修改。
添加数据源：
- 点击左侧齿轮 → Data Sources → Add data source → 选择 Prometheus。
- URL 填写 Prometheus 的地址（例如
http://localhost:9090），点击 Save & Test 显示成功。
创建磁盘 await 面板：
- 点击 + → Create → Dashboard → Add visualization。
- 在 Query 中输入上面提到的 PromQL：
rate(node_disk_io_time_seconds_total{device=~"sd[a-z]|nvme[0-9]n[0-9]"}[1m]) * 1000 / (rate(node_disk_reads_completed_total{device=~"sd[a-z]|nvme[0-9]n[0-9]"}[1m]) + rate(node_disk_writes_completed_total{device=~"sd[a-z]|nvme[0-9]n[0-9]"}[1m]))注意：device 过滤要匹配实际的磁盘名，常见的有 sda、sdb、nvme0n1 等。可以在 node_disk_io_time_seconds_total 的 metrics 中查看可用的 device 值。
- 面板类型选择 Time series，设置单位（毫秒），标题为“磁盘 await 延迟”。
- 保存后，你就能看到每条磁盘的 await 随时间变化的曲线了。
进阶阅读：此处可内链到“Prometheus Node性能优化”指南。
关联教程：此处可内链到“Prometheus Node部署与验证”内容。
如何解读 await 数据？——Prometheus Node
正常范围 vs 异常
- SATA SSD：await 一般在 1-3ms 以内。
- NVMe SSD：通常在 0.1-0.5ms，超过 1ms 就需要关注。
- 机械硬盘：在无随机读写时约 10-20ms，随机读写时可能飙升到 100ms 以上。
但这些数值只是经验参考。更重要的观察方式是：监控趋势。如果某块磁盘的 await 从平时的 2ms 突然跳到 10ms 并持续不下，说明磁盘负载增加了或者出现了异常。
await 高可能的原因
- 磁盘 I/O 饱和：读写请求太多，超过了磁盘的处理能力。可以结合
node_disk_io_now（当前正在处理的 I/O 数）和avgqu-sz（平均队列长度）来确认。 - 硬件故障：磁盘坏道、控制器故障等，此时通常伴随
node_disk_io_time_seconds_total增长异常缓慢。 - 文件系统层面问题：例如 ext4 的 journal 压力过大、XFS 的元数据操作卡顿。
- 内核参数或调度器：I/O 调度器选择不当（例如 deadline 更适合机械盘，noop 适合 SSD）。
结合其他指标综合分析
await 不是孤立的，需要与 iowait（CPU 等待 I/O 的时间百分比）、svctm（实际服务时间，现代系统已不准确）、util（磁盘利用率）一起看。如果 await 高但 util 低，可能是有很多小文件碎片导致寻道慢；如果 util 接近 100%，说明磁盘确实被压满了。
相关阅读：此处可内链到“Prometheus Node常见问题”专题。
从监控到调优：下一步怎么做
配置前的检查
发现 await 偏高后，常见的应对策略包括：
- 升级硬件：HDD → SSD，SATA SSD → NVMe SSD。
- 优化应用：减少不必要的磁盘写操作，使用缓存（如 Redis）降低 I/O 压力。
- 调整内核参数：修改 I/O 调度器，调整
vm.dirty_ratio和vm.dirty_background_ratio等。 - 分散负载：将高 I/O 的服务分配到不同的物理磁盘或使用 RAID0/10。
但任何调优都应该基于监控数据，而不是盲目操作。Prometheus 的长期记录可以帮助你对比优化前后的效果。
常见问题与避坑
先看关键判断
- Q：为什么计算出来的 await 有时是负数？
可能是因为磁盘计数器重置（比如重启或磁盘移除），导致 rate 计算出现短暂异常，通常忽略即可。 - Q：需要监控所有磁盘吗？
建议只监控实际存数据的盘（如sda、nvme0n1），忽略 RAM disk 或 loop 设备，否则指标太多且无意义。 - Q：可以用 iostat 替换吗？
iostat 是命令行工具，适合临时排查；Prometheus 适合长期趋势和告警。二者互补，推荐都用。
最后提醒：不要只盯着 await 一个指标，它只是硬盘性能的一个“仪表盘”，要真正判断问题，还需要结合上下文。希望本文能帮你建立起对磁盘 I/O 延迟的感性认知和实操能力。把这些步骤跑通后，Prometheus Node基本就能稳定落地。
延伸阅读