跳转至

19. 硬盘监控

本章介绍 RHEL 9 的硬盘健康监控与 I/O 性能分析:smartmontools SMART 健康检查与 smartd 自动告警、sysstat(iostat/sar)历史 I/O 性能采集、磁盘空间自动告警脚本,以及通过 Prometheus Node Exporter 将磁盘指标接入第 18 章已建立的监控体系。硬盘故障通常有前兆,及时发现并预警可将数据损失降至最低。


19.1 前提条件

  • 已完成第三阶段前序配置(第 15–18 章),Prometheus 与 Node Exporter 已运行。
  • 通过 SecureCRT(SSH 端口 2222)以 ops 用户、密钥认证方式登录 192.168.1.100,执行 sudo -i 切换至 root 环境。
  • EPEL 仓库已启用(第 7 章),官方仓库已启用。

安装本章所需工具:

dnf install -y smartmontools sysstat iotop

本章全局参数

参数
主机名 / IP linuxdc / 192.168.1.100
监控磁盘 /dev/sda(系统盘)
磁盘告警脚本路径 /usr/local/bin/disk-alert.sh
告警阈值 磁盘使用率 80%
Prometheus 规则文件 /etc/prometheus/rules/disk-alerts.yml

19.2 SMART 健康监控(smartmontools)

SMART(Self-Monitoring, Analysis and Reporting Technology)是硬盘内置的自我监测机制,能够在物理故障发生前通过属性变化提供预警,是生产服务器硬盘健康管理的基础手段。

虚拟机说明

VMware 虚拟磁盘默认不透传 SMART 数据,smartctl -i /dev/sda 可能报告 SMART support is: Unavailable。可在 VMware 虚拟机设置 → 磁盘 → 启用 SMART 透传解决,或在物理机环境中执行本节操作。本节命令以 /dev/sda 为示例。

19.2.1 查看磁盘基本信息

# 扫描系统中所有支持 SMART 的磁盘
smartctl --scan

# 查看磁盘基本信息(型号、序列号、固件版本、接口类型)
smartctl -i /dev/sda

# 确认 SMART 支持状态
smartctl -i /dev/sda | grep -E "SMART support|Device Model|Capacity|Interface"

19.2.2 健康状态快速检查

# 最简健康检查(结果只有 PASSED 或 FAILED)
smartctl -H /dev/sda

# 查看完整 SMART 属性(所有监控指标及阈值)
smartctl -A /dev/sda

# NVMe SSD 查看方式
smartctl -A /dev/nvme0

关键 SMART 属性说明:

属性名 ID 含义 警戒条件
Reallocated_Sector_Ct 5 已重映射的坏扇区数 非 0 需关注,持续增长须立即换盘
Spin_Retry_Count 10 主轴启动重试次数 非 0 表示机械结构故障风险
Reallocated_Event_Count 196 重映射事件总次数 持续增长预示磁盘老化
Current_Pending_Sector 197 待处理不稳定扇区数 非 0 为潜在坏扇区强烈信号
Offline_Uncorrectable 198 离线无法纠正扇区数 非 0 须立即备份并准备换盘
Temperature_Celsius 194 磁盘当前温度(°C) 机械盘 > 55°C、SSD > 70°C 需检查散热
Power_On_Hours 9 通电累计小时数 机械盘 > 30000 小时需评估更换
# 快速提取关键健康指标
smartctl -A /dev/sda | grep -E \
  "Reallocated_Sector|Current_Pending|Offline_Uncorrectable|Temperature|Power_On_Hours"

19.2.3 执行 SMART 自检测试

# 短测试(1–2 分钟,检查最关键部分,可在业务低峰随时执行)
smartctl -t short /dev/sda

# 等待约 2 分钟后查看测试结果
smartctl -l selftest /dev/sda

# 长测试(数小时,全盘扫描,须在计划维护窗口内执行)
smartctl -t long /dev/sda

# 查看所有历史测试结果
smartctl -l selftest /dev/sda

测试时机建议

短测试可在业务低峰期随时发起;长测试期间磁盘 I/O 性能会明显下降,应安排在计划停机窗口内执行,避免影响生产业务。

19.2.4 配置 smartd 自动后台监控

smartd 在后台持续轮询磁盘健康状态,检测到异常时写入 syslog 并可触发邮件告警,是硬盘健康监控自动化的核心。

# 备份默认配置
cp /etc/smartd.conf /etc/smartd.conf.orig

vim /etc/smartd.conf

清空默认内容,写入以下标准配置:

# 监控 /dev/sda
# -a     监控所有 SMART 属性,任何属性值恶化时告警
# -o on  启用自动离线测试(后台静默执行,对性能影响极小)
# -S on  启用自动属性保存(保存历史数据用于趋势分析)
# -s     定期自检计划:每天凌晨 02:00 执行短测试,每周日凌晨 04:00 执行长测试
# -m     故障告警邮件发送至 root(需配置 MTA,如 Postfix)
# -M     告警策略:diminishing = 首次告警后,相同问题的重复告警间隔递增

/dev/sda -a -o on -S on \
  -s (S/../.././02|L/../../7/04) \
  -m root \
  -M diminishing

测试计划格式说明(-s 参数):

格式:类型/月/日/星期/小时
S = Short(短测试),L = Long(长测试),. = 任意值

S/../.././02    每天(任意月任意日任意星期)凌晨 02:00 执行短测试
L/../../7/04    每周日(星期 7)凌晨 04:00 执行长测试
# 启用并启动 smartd
systemctl enable --now smartd
systemctl status smartd

# 验证 smartd 已开始监控
journalctl -u smartd -n 20

检查点

systemctl is-active smartd 返回 activejournalctl -u smartd 显示类似 Device: /dev/sda, opened 的监控启动日志。


19.3 磁盘 I/O 性能监控(sysstat)

sysstat 工具集提供系统级性能历史数据的持久化采集,其中 iostat 用于实时 I/O 分析,sar 用于查询历史数据,是磁盘性能问题排查的核心工具链。

19.3.1 启用 sysstat 历史数据采集

systemctl enable --now sysstat
systemctl status sysstat

# 配置历史数据保留策略
vim /etc/sysconfig/sysstat

修改以下字段:

# 保留 30 天的历史采集数据(默认 7 天)
HISTORY=30

# 超过 10 天的历史数据自动压缩节省空间
COMPRESSAFTER=10
systemctl restart sysstat

# 验证历史数据目录
ls -lh /var/log/sa/

19.3.2 iostat — 实时 I/O 监控

# 每 5 秒刷新,显示扩展磁盘统计(含详细 I/O 指标)
iostat -dx 5

# 仅查看特定磁盘
iostat -dx 5 /dev/sda

# 以 MB/s 为单位显示吞吐量
iostat -dm 5

iostat 关键指标解读:

指标 说明 警戒参考值
%util 磁盘利用率(I/O 繁忙时间占比) > 80% 表示接近饱和
await 平均 I/O 等待时间(ms) SSD < 1ms,机械盘 < 20ms
r/s / w/s 每秒读 / 写请求数(IOPS) 超过磁盘额定 IOPS 则饱和
rMB/s / wMB/s 每秒读 / 写吞吐量 超过磁盘带宽规格则饱和
avgqu-sz 平均 I/O 队列长度 持续 > 1 表示 I/O 积压

19.3.3 sar — 历史数据分析

# 查看今日磁盘 I/O 历史(每 10 分钟一条采样记录)
sar -d -p 1 5

# 查看指定日期历史数据(如每月 23 日)
sar -d -p -f /var/log/sa/sa23

# 查看今日 CPU 历史
sar -u

# 查看今日内存历史
sar -r

# 查看今日网络 I/O 历史
sar -n DEV

# 生成今日完整性能报告
sar -A > /tmp/sar-report-$(date +%F).txt

19.3.4 iotop — 进程级 I/O 监控

当系统 I/O 整体偏高时,iotop 用于定位"元凶"进程:

# 实时显示有 I/O 活动的进程(-o 仅显示有活动的)
iotop -o

# 非交互模式:采集 5 次,每次间隔 2 秒
iotop -o -b -d 2 -n 5

19.4 磁盘空间监控与自动告警

19.4.1 实时空间与 inode 查看

# 查看所有文件系统使用情况(含类型)
df -hT

# 查看 inode 使用情况(inode 耗尽与空间耗尽同样危险)
df -i

# 逐层定位大目录
du -sh /var/* | sort -rh | head -10
du -sh /var/log/* | sort -rh | head -10

# 查找大于 100 MB 的文件
find / -xdev -type f -size +100M \
  -exec ls -lh {} \; 2>/dev/null | sort -rk5 | head -20

19.4.2 磁盘空间告警脚本

tee /usr/local/bin/disk-alert.sh << 'EOF'
#!/bin/bash
# 磁盘空间告警脚本
# 当任意挂载点使用率超过阈值时写入 syslog 和告警日志

THRESHOLD=80
LOG="/var/log/disk-alert.log"

df -hTP | tail -n +2 | grep -v tmpfs | while read line; do
    USAGE=$(echo "$line" | awk '{print $6}' | tr -d '%')
    MOUNT=$(echo "$line" | awk '{print $7}')
    FS=$(echo "$line" | awk '{print $3}')

    if [ -n "$USAGE" ] && [ "$USAGE" -ge "$THRESHOLD" ] 2>/dev/null; then
        MSG="DISK ALERT: ${MOUNT} (${FS}) usage is ${USAGE}% (threshold: ${THRESHOLD}%)"
        logger -t disk-alert -p local0.warn "$MSG"
        echo "$(date '+%F %T') $MSG" >> "$LOG"
    fi
done
EOF

chmod +x /usr/local/bin/disk-alert.sh

配置 systemd timer,每 30 分钟自动检查一次:

tee /etc/systemd/system/disk-alert.service << 'EOF'
[Unit]
Description=Disk Space Alert Check

[Service]
Type=oneshot
ExecStart=/usr/local/bin/disk-alert.sh
StandardOutput=journal
StandardError=journal
EOF

tee /etc/systemd/system/disk-alert.timer << 'EOF'
[Unit]
Description=Disk Space Alert Timer
Requires=disk-alert.service

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Persistent=true

[Install]
WantedBy=timers.target
EOF

systemctl daemon-reload
systemctl enable --now disk-alert.timer

# 手动触发一次测试
systemctl start disk-alert.service
journalctl -u disk-alert.service -n 10

19.5 接入 Prometheus 磁盘监控

第 18 章已部署的 Node Exporter 默认采集全量磁盘指标,无需额外配置即可在 Grafana 中可视化。

19.5.1 验证磁盘指标已采集

# 查看 Node Exporter 采集的磁盘 I/O 指标
curl -s http://localhost:9100/metrics | grep "^node_disk" | head -20

# 文件系统空间指标
curl -s http://localhost:9100/metrics | grep "node_filesystem_avail_bytes"

# 磁盘 I/O 时间指标
curl -s http://localhost:9100/metrics | grep "node_disk_io_time_seconds_total"

19.5.2 在 Prometheus 中查询磁盘指标

通过浏览器访问 http://192.168.1.100:9090,在查询框中执行以下 PromQL:

# 根分区使用率(百分比)
100 - (
  node_filesystem_avail_bytes{mountpoint="/",fstype!="tmpfs"}
  * 100
  / node_filesystem_size_bytes{mountpoint="/",fstype!="tmpfs"}
)

# 磁盘 I/O 利用率(过去 5 分钟平均,百分比)
rate(node_disk_io_time_seconds_total{device="sda"}[5m]) * 100

# 磁盘读取速率(MB/s)
rate(node_disk_read_bytes_total{device="sda"}[5m]) / 1024 / 1024

# 磁盘写入速率(MB/s)
rate(node_disk_written_bytes_total{device="sda"}[5m]) / 1024 / 1024

19.5.3 添加磁盘 I/O 与预测性告警规则

在第 18 章创建的告警规则文件中追加磁盘 I/O 告警和预测性空间告警:

tee -a /etc/prometheus/rules/disk-alerts.yml << 'EOF'

      - alert: DiskIOHigh
        expr: rate(node_disk_io_time_seconds_total{device="sda"}[5m]) * 100 > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "磁盘 I/O 利用率过高 ({{ $labels.instance }})"
          description: "磁盘 {{ $labels.device }} I/O 利用率超过 80%,当前值: {{ $value | printf \"%.1f\" }}%"

      - alert: DiskWillFillIn24h
        expr: >
          predict_linear(
            node_filesystem_avail_bytes{mountpoint="/",fstype!="tmpfs"}[6h],
            24 * 3600
          ) < 0
        for: 30m
        labels:
          severity: critical
        annotations:
          summary: "磁盘预计 24 小时内写满 ({{ $labels.instance }})"
          description: "根据当前 6 小时写入趋势,根分区预计在 24 小时内耗尽空间"
EOF

systemctl reload prometheus

predict_linear 预测性告警的优势

predict_linear 基于过去 6 小时的历史趋势预测未来可用空间,能在磁盘实际写满前数小时发出告警,为运维人员预留充裕的处置时间(清理、扩容、数据迁移),将潜在故障消灭在发生之前。相比固定阈值告警(如 > 90%),预测性告警的响应窗口更宽,是生产环境的最佳实践。


19.6 常见问题与排查

问题现象 排查步骤
smartctl -H 返回 FAILED 立即备份数据;smartctl -A /dev/sda 定位哪项属性超阈值;联系硬件维护更换磁盘
smartctlSMART support is: Unavailable 虚拟机磁盘不支持;尝试 smartctl -d sat -H /dev/sda 指定接口类型
sysstat 历史文件为空 systemctl status sysstat;检查定时采集任务:systemctl list-timers | grep sysstat
iostat %util 持续 100% 磁盘 I/O 饱和;iotop -o 定位高 I/O 进程;考虑增加磁盘或迁移热数据至 SSD
Prometheus 磁盘指标缺失 curl http://localhost:9100/metrics | grep node_disk 验证采集正常;检查 Node Exporter 运行状态
# 综合磁盘诊断一键脚本
echo "=== SMART 健康状态 ===" && smartctl -H /dev/sda
echo "=== 磁盘空间使用 ===" && df -hT
echo "=== 当前 I/O 状态 ===" && iostat -dx 1 3 | tail -10
echo "=== 近期 I/O 历史 ===" && sar -d 1 5 2>/dev/null | tail -10

19.7 实践任务

  1. 登录 linuxdc(SecureCRT 端口 2222,ops 用户,密钥认证,sudo -i 切换 root)。
  2. 检查 /dev/sda SMART 健康状态,提取关键属性:

    smartctl -H /dev/sda
    smartctl -A /dev/sda | grep -E "Reallocated|Pending|Uncorrectable|Temperature|Power_On_Hours"
    
  3. 配置 /etc/smartd.conf,启用 smartd 自动监控,验证 journal 日志:

    systemctl enable --now smartd
    journalctl -u smartd -n 10
    
  4. 启用 sysstat 并配置 30 天历史,执行 I/O 监控:

    systemctl enable --now sysstat
    iostat -dx 5 3
    sar -d 1 5
    
  5. 创建磁盘空间告警脚本,配置 systemd timer 每 30 分钟检查,手动触发验证:

    systemctl start disk-alert.service
    journalctl -u disk-alert.service -n 10
    
  6. 在 Prometheus 查询根分区使用率指标,在 Grafana 的 Node Exporter Full 面板中验证磁盘指标正常显示。

  7. 追加 DiskIOHighDiskWillFillIn24h 告警规则,执行 systemctl reload prometheus 使规则生效。

19.8 自测问题

Q1:SMART 属性 Current_Pending_Sector 非零代表什么,应如何处置?

该属性表示磁盘存在"待处理不稳定扇区"——这些扇区在读取时出现过错误,但尚未被确认为永久坏扇区。这是磁盘即将发生物理故障的强烈预警信号,正确处置步骤为:① 立即将该磁盘上的全部数据备份至其他存储;② 执行 SMART 长测试确认故障范围;③ 在最近的维护窗口内更换磁盘,不应继续将其用于存储重要生产数据。

Q2:iostat -dxawait 值偏高(机械盘超过 50ms)说明什么,如何定位根因?

await 是 I/O 请求从提交到完成的平均等待时间,包含队列等待和磁盘服务时间。机械盘 await 超过 50ms 通常意味着 I/O 队列积压(同步查看 avgqu-sz 持续 > 1)、磁盘 I/O 接近或已达到饱和(%util 接近 100%),或磁盘本身出现物理问题(结合 SMART 检查 Reallocated_Sector_Ct)。定位流程:先用 iotop -o 找出高 I/O 进程,再结合 smartctl -A 判断是否为硬件问题,最后决定是优化应用 I/O 模式还是升级硬件。

Q3:Prometheus 的 predict_linear 预测性告警相比固定阈值告警有何优势?

固定阈值告警(如使用率 > 90%)是被动响应,发出告警时磁盘可能仅剩数 GB 甚至数百 MB,留给运维人员的处置时间极其有限,高写入场景下可能来不及扩容便已写满。predict_linear 基于过去 6 小时的历史增长趋势线性外推,能在磁盘实际耗尽前 24 小时以上发出告警,给运维团队充裕的时间执行清理(旧日志、过期备份)、在线扩容(LVM/VDO)或数据迁移操作,将潜在磁盘满故障消灭在发生之前。


19.9 章节总结

本章建立了 RHEL 9 硬盘监控的完整体系:smartmontools 实现 SMART 属性健康检查与 smartd 后台自动监控告警(短测试/长测试定期调度);sysstat(iostat/sar)提供历史 I/O 性能数据采集分析(保留 30 天,iotop 定位高 I/O 进程);自定义磁盘空间告警脚本通过 systemd timer 每 30 分钟自动巡检;Prometheus Node Exporter 将磁盘空间、I/O 利用率等指标无缝融入第 18 章的监控体系,并通过 predict_linear 实现预测性容量告警。

至此,第三阶段数据存储与管理架构全部完成。系统已建立起从物理存储(磁盘/LVM/VDO)到网络共享(NFS/Samba)、数据保护(备份/恢复)、可观测性(日志/指标/告警)的完整闭环,具备进入第四阶段(Web/数据库/容器服务部署)的全部基础条件。