健康检查清单

大部分故障在爆发前都有征兆：池慢慢写满、一块盘的坏道在增加、某个服务反复重启。这份清单用十分钟把这些征兆找出来。

建议每月跑一次，在日历上设个重复提醒。

一次跑完的脚本

先给完整版，下面逐项解释。在宿主机 shell 执行：

echo "===== 版本 ====="
pveversion

echo "===== 系统盘空间 ====="
df -h / /var/lib/vz

echo "===== 存储状态 ====="
pvesm status

echo "===== LVM thin pool ====="
lvs -a 2>/dev/null | grep -E 'Data%|twi'

echo "===== ZFS 池 ====="
zpool status 2>/dev/null
zpool list 2>/dev/null

echo "===== 失败的服务 ====="
systemctl --failed

echo "===== 内存 ====="
free -h

echo "===== 客户机 ====="
qm list
pct list

echo "===== 最近的错误日志 ====="
journalctl -p err -b --no-pager | tail -30

这个脚本是只读的

上面所有命令都只读取状态，不修改任何东西。可以放心执行。把它存成 /root/healthcheck.sh 并 chmod +x，以后一条命令跑完。

逐项看什么

1. 存储空间（最常见的问题来源）

df -h /

红线：/ 使用率超过 85%。

系统盘满了会导致日志写不进去、服务启动失败、客户机无法启动。常见元凶：

du -sh /var/lib/vz/* 2>/dev/null | sort -h
journalctl --disk-usage

/var/lib/vz/dump/ 大 → 备份存在系统盘上了，挪走。
/var/lib/vz/template/iso/ 大 → 删掉用不上的 ISO。
日志大 → journalctl --vacuum-size=500M

2. LVM thin pool

lvs -a

看 data 那行的 Data% 和 Meta%。

红线：Data% 或 Meta% 超过 80%

thin pool 写满时，运行中客户机的写入会失败，文件系统可能损坏。而且 Meta%（元数据）满了同样致命，它的容量比 Data 小得多，容易被忽略。

超过 80% 就要处理：删掉不用的客户机和快照、清理客户机内部空间并触发 TRIM、或者扩容。见 local 与 local-lvm。

顺便检查有没有忘记删的快照：

# 列出所有虚拟机的快照
for id in $(qm list | awk 'NR>1 {print $1}'); do
  echo "--- VM $id ---"
  qm listsnapshot $id
done

3. ZFS 池

zpool status

必须是：

state: ONLINE
errors: No known data errors

DEGRADED 要当作紧急情况

池进入 DEGRADED 说明冗余已经用掉了，再坏一块（mirror 或 raidz1）数据就没了。

立刻：确认备份可用 → 订/换硬盘 → 尽快替换。不要想着「还能跑」。

还要看 scan: 那行的上次 scrub 时间。超过一个月没 scrub，手动跑一次：

zpool scrub <poolname>

容量也要看（ZFS 的 df 不准）：

zfs list

ZFS 池不要写太满

ZFS 在池接近满（通常说 80%–90% 以上）时，写入性能会明显下降，因为它难以找到连续空间。把 80% 当作该清理的信号。

4. 硬盘健康（SMART）

Web UI：节点 → Disks，看每块盘的 S.M.A.R.T. 列，正常是 PASSED。

命令行看细节：

smartctl -a /dev/sda | grep -E 'Reallocated|Pending|Uncorrectable|Power_On_Hours|Temperature'

关注这几项是否在增长：

属性	含义
`Reallocated_Sector_Ct`	已重映射的坏扇区。从 0 变成非 0 就要警惕
`Current_Pending_Sector`	等待重映射的可疑扇区。非 0 是明确的警告
`Offline_Uncorrectable`	无法纠正的错误

绝对值不如趋势重要

一块盘有 4 个重映射扇区，稳定了两年没变，通常不用紧张。一块盘上个月是 0、这个月是 4，那是明确的信号。

所以每月记录一次这些数字，比只看当前值有价值得多。

SMART PASSED 不代表盘没问题——它只说明没触发厂商设定的阈值。SMART 报警时盘往往已经很危险了。

5. 服务状态

systemctl --failed

理想输出是 0 loaded units listed。有失败的服务就查：

systemctl status <服务名>
journalctl -u <服务名> -n 50 --no-pager

PVE 的核心服务：

systemctl status pve-cluster pvedaemon pveproxy pvestatd

6. 内存

free -h

用 ZFS 时 available 才是真实可用量

free -h 的 used 列会把 ZFS 的 ARC 缓存算进去，看起来内存快满了。看 available 列——它考虑了可回收的缓存。

如果 available 也很小，说明真的紧张了。检查 ARC 上限设置，见 ZFS 入门。

7. 客户机状态

qm list
pct list

确认：

该跑的都在跑（running）。
没有意外停掉的。
没有你已经忘了的、还占着资源的僵尸客户机。

顺便清理

每次检查时问一句：这台客户机我还在用吗？删掉不用的能省下内存、磁盘和备份空间。删之前先备份一份留着。

8. 备份

这一项最重要，但没法用一条命令看完。

数据中心 → 备份 → 任务日志，或者：

# 看最近的备份任务
grep -i vzdump /var/log/syslog | tail -20

# 看备份存储里有什么
pvesm list <备份存储名> --content backup | tail -20

确认：

最近一次备份成功（不只是「跑过」）。
备份文件的时间是近期的。
每台重要客户机都在备份列表里——特别是最近新建的那些。
备份存储的剩余空间够用。

最容易出问题的是「新建的客户机没进备份」

如果备份任务用的是手动勾选模式，新建的客户机不会自动加入。每月检查时对一遍 qm list 和备份列表。

治本的办法是把备份任务改成 **All（全选）**模式。

9. 最近的错误日志

journalctl -p err -b --no-pager | tail -30

-p err 只看错误级别以上，-b 是本次启动以来。

翻一遍，重点关注反复出现的条目。偶发的一两条通常无害，每分钟重复一次的一定有问题。

10. 更新

apt update && apt list --upgradable

有安全更新就安排时间装，见更新与大版本升级。

记录下来

建一个简单的记录

每次检查把关键数字记一行：

text

2026-09-22  /=42%  thin=61%  zpool=ONLINE  ARC=7.8G  sda重映射=0  备份=OK

一年下来这个文件比任何监控图表都实用——它能让你一眼看出什么在慢慢变差。

什么时候该上真正的监控

这份手动清单适合单机和少量客户机。出现这些信号时，考虑上自动监控（Prometheus + Grafana，或 PVE 内置的指标导出）：

节点数量超过两三台。
出现过「问题已经发生了几天才发现」的情况。
有人依赖你的服务，中断有实际代价。

自动监控的配置见监控与告警。

健康检查清单 ​

一次跑完的脚本 ​

逐项看什么 ​

1. 存储空间（最常见的问题来源） ​

2. LVM thin pool ​

3. ZFS 池 ​

4. 硬盘健康（SMART） ​

5. 服务状态 ​

6. 内存 ​

7. 客户机状态 ​

8. 备份 ​

9. 最近的错误日志 ​

10. 更新 ​

记录下来 ​

什么时候该上真正的监控 ​

延伸阅读 ​