psutil.disk_usage()通过statvfs()获取实时磁盘使用率，比df -h更准确；需传标准化绝对路径，监控应判连续阈值而非瞬时峰值，并以systemd type=simple长期运行。
用 psutil 获取真实磁盘使用率，别信 df -h 的缓存值
Linux 的 df 命令默认显示的是挂载点的统计，但内核可能缓存了部分元数据，导致短时间重复调用结果滞后。而 psutil.disk_usage(path) 底层调用 statvfs()，直接读取当前内核视图，更及时。监控根分区时，传 '/'；监控 /data 就传 '/data'。注意：路径必须存在且可访问，否则抛 FileNotFoundError。
常见错误是传错路径字符串——比如写成 '/data/'（末尾斜杠）却没做 os.path.normpath() 标准化，在某些挂载配置下会意外失败。建议统一用 os.path.abspath() 处理输入路径。
示例片段：
import psutil
usage = psutil.disk_usage('/')
print(f"已用: {usage.percent:.1f}%") # 返回 float，非字符串
阈值触发逻辑要区分“瞬时峰值”和“持续越界”
磁盘涨到 95% 可能只是某个日志轮转瞬间的事，立刻发报警反而造成干扰。真正该报警的是“连续 3 次检测（间隔 30 秒）都 ≥92%”。用一个长度为 3 的列表或 deque 记录最近三次的 percent 值，每次新值追加、老值弹出，再用 all(v >= 92.0 for v in history) 判断。
不要用简单 if 判断单次值——线上环境里，du 扫描、rsync 写入、容器镜像拉取都可能引发秒级尖峰，这类毛刺不值得告警。
关键点：
-
psutil.disk_usage()调用本身很快（微秒级），但频繁调用（如每 5 秒）对 I/O 几乎无压力 - 避免在循环里反复调用
psutil.disk_partitions()获取所有挂载点——它涉及 /proc/mounts 解析，开销大；应预先过滤出目标路径再查 usage - 若监控多个路径，别用嵌套循环，改用列表推导式批量采集
用 subprocess 发邮件或调用企业微信机器人，别硬编码 SMTP 密码
明文写密码在脚本里等于裸奔。把邮箱密码、Webhook URL 这类敏感信息抽到外部文件（如 /etc/diskmon/secrets.json），用 json.load() 读取，并确保该文件权限为 600（chmod 600 /etc/diskmon/secrets.json）。Python 进程启动用户需有读取权限。
发邮件推荐走本地 sendmail（无需认证，依赖系统配置），命令形如：['sendmail', '-t']，然后把完整邮件内容（含 headers）喂给 stdin。比用 smtplib 更轻量、更少 TLS 兼容问题。
调用企业微信机器人则用 requests.post()，注意设置 timeout=(5, 10) 防卡死，且检查响应状态码是否为 200 和 resp.json().get('errcode') == 0，否则记录失败日志而非静默忽略。
部署为 systemd service 时，Type=oneshot 是错的
监控必须长期运行，不能用 Type=oneshot（执行完就退出）。正确设为 Type=simple，并配 Restart=always 和 RestartSec=10。否则进程崩溃后不会自拉起，监控就断了。
另外两个易漏点：
- 在 service 文件里加
Environment="PYTHONPATH=/opt/diskmon"，避免因路径问题导入不到自定义模块 - 用
StandardOutput=journal+StandardError=journal，这样journalctl -u diskmon.service就能查日志，别重定向到文件再搞 logrotate - 如果脚本里用了
time.sleep(30)，记得在 service 中加StartLimitIntervalSec=0，否则 systemd 可能误判为“频繁崩溃”而拒启
真正难的不是取值或发消息，而是让这个进程在服务器重启、OOM killer 杀掉、磁盘满导致 Python 无法写临时文件等极端情况下，还能被 systemd 拉起来、继续干活——这些边界得靠配置兜底，不是代码能全 cover 的。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
