psutil.cpu_percent()的interval参数必须≥1，否则返回上次差值或0；memory.percent是已用占比非剩余；disk_usage不依赖时间窗口但需确认挂载点；监控自身资源会干扰结果，应限制其cpu配额。
psutil.cpu_percent() 的 interval 参数必须设为 1 或更大
直接调用 psutil.cpu_percent() 不传 interval 会返回上次调用的差值，首次调用永远是 0 —— 这不是 bug，而是设计机制。你看到的 “CPU 始终为 0%” 就是这个原因。
-
interval=1是最小有效值：它会让 psutil 等待 1 秒，再计算这 1 秒内的平均使用率，结果才真实可比 - 不要设
interval=0：虽然语法合法，但返回的是“瞬时快照”，在 Linux 上实际等价于上一次采样值，毫无意义 - 高频率轮询（如
interval=0.1）不仅不准，还会显著抬高自身 CPU 占用 —— 监控程序自己成了性能瓶颈
psutil.virtual_memory().percent 返回的是已用内存占比，不是“剩余”
新手常误以为 memory_info.percent 是空闲率，结果告警逻辑写反：比如设阈值 80%，本意是“用超 80% 就告警”，却当成“剩不到 20% 才告警”，导致漏报。
-
psutil.virtual_memory()返回对象的.percent字段定义明确：(used/total) × 100 - 真正需要“可用内存不足”告警时，应优先看
.available字段（单位字节），而不是依赖.percent - Linux 下
.available已包含 page cache 可回收部分，比free -h中的 “available” 更贴近真实可用量
单次采集不能反映趋势，连续采样需注意时间窗口对齐
很多脚本每 5 秒跑一次 psutil.cpu_percent(interval=1)，看似合理，实则采样点错位：第 1 次耗时 1 秒，休眠 4 秒；第 2 次又耗时 1 秒……实际间隔是 5 秒，但 CPU 统计覆盖的是不连续的 1 秒片段，容易漏掉短时尖峰。
- 若需检测“过去 60 秒内 CPU 是否持续 >90%”，不能靠 12 次独立
interval=1结果取平均 —— 应改用psutil.cpu_times_percent(percpu=False, interval=60) - 内存泄漏检测场景下，
psutil.virtual_memory().percent每分钟采一次足够，但必须确保采样时刻稳定（如用time.sleep(60 - time.time() % 60)对齐整分钟） - 磁盘使用率
psutil.disk_usage('/').percent可以单次调用，它不依赖时间窗口，但要注意路径是否挂载 ——'/'在容器里可能不是根文件系统
监控进程自身资源占用会干扰结果
用同一个 Python 进程既采集指标又做告警判断，它的 CPU 和内存开销会被计入系统统计，尤其在低配服务器上，自身占用可能达 3–5%，导致告警阈值失真。
- 避免在采集循环里做复杂计算（如实时绘图、日志格式化、HTTP 请求）—— 这些应剥离到单独协程或子进程
- 用
psutil.Process().cpu_percent()监控自身 CPU 占用，一旦超过 3%，就该优化逻辑或降频采集 - 生产环境建议用 systemd 或 supervisor 管理监控进程，并限制其 CPU quota（如
CPUQuota=5%），防止失控
真正难的不是拿到数字，而是让每个数字在正确的时间、以正确的含义、被正确的人看到。比如 psutil.cpu_percent(interval=1) 返回 99.9%，它可能意味着业务正满负荷运行，也可能只是你刚启了一个 top 命令 —— 区分这两者，靠的不是更多代码，而是采集上下文和告警分级策略。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
