前阵子公司一台线上服务CPU突然飙到100%我用系统自带的任务管理器看了半天除了一个pid能锁定剩下的信息全靠猜。后来发现这个进程是哪个服务的、占了多少内存、网络连了哪里全是黑盒。那次之后我花了两天把psutil完整过了一遍从此系统监控再也没用过命令行的临时组合拳。这篇文章就把这套东西的用法、原理和我踩过的坑一次性讲透。1. 为什么选psutil核心思路与架构拆解1.1 psutil到底解决了什么问题psutil全称是process and system utilities它是Python生态里少有的把系统监控与进程管理做得既完整又统一的库。它最大的价值不是某个函数多厉害而是把CPU、内存、磁盘、网络、传感器、进程、系统启动时间这些分散在操作系统各处的信息全部收拢到一套跨平台接口下并且API设计得极其规整。在Linux上你想看CPU使用率可以用top或者vmstat到了Windows上就得换tasklist、typeperf再换到macOS又得换top、iostat。系统之间命令不一样输出格式不一样解析方式也不一样。用psutil直接从Python层面拿结构化数据同样是cpu_percent()从Linux到Windows返回的字段与口径完全一致脚本逻辑不用改动一行就能跑通另一个平台。这套库特别适合两类场景。一类是写通用的运维脚本比如服务器资产采集、告警机器人、自研监控系统另一类是深度系统级工具比如要在程序里实时识别谁在疯狂吃资源、要在自动化测试里判断系统是否已达瓶颈、要做一个带图形界面的系统监视器。如果只是临时看一眼机器状态命令行工具确实够用但只要涉及程序化分析和自动处理psutil几乎是绕不开的基础设施。还有一点很重要psutil虽然用起来是纯Python接口但底层很多采集逻辑是直接对接系统原生接口的性能开销很低高频轮询也不会对被测系统产生明显的资源消耗。我在4核8GB的云服务器上做过实测每秒调用一轮cpu_percent、virtual_memory、disk_io_counters、net_io_counters额外CPU消耗基本在1%以内这点对于生产环境非常关键。1.2 核心模块与设计玄机psutil按数据域划分模块每个模块对应一类系统资源。psutil.cpu_*CPU核心数、频率、使用率、负载、运行队列psutil.virtual_memory / swap_memory物理内存与交换分区psutil.disk_*磁盘分区、磁盘使用率、磁盘IOpsutil.net_*网卡信息、网络连接、网络IOpsutil.sensors_*温度、风扇、电池psutil.Process() 与 psutil.pids()进程管理psutil.boot_time / users / users系统启动时间与登录用户这个模块划分看起来简单但设计上有个关键点是“常驻系统级信息”与“进程级快照信息”分离。常规系统级API直接用函数调用比如psutil.cpu_percent()而进程级信息则通过psutil.Process(pid)创建对象后再拿属性。这种分层好在哪你可以在一个脚本里同时盯一整台机器的全局指标和某一组特定进程的细节互不干扰。另一个容易被忽略的玄机是psutil几乎所有快照型API都返回namedtuple或自定义对象字段名和位置下标都能用。比如psutil.virtual_memory()返回的对象你可以通过.total、.used也可以通过[0]、[1]访问。写代码时优先按字段名取可读性和可维护性都远胜下标访问。2. 环境准备与快速上手2.1 安装与版本选择安装极其简单pip直接装。pip install psutil如果你在用conda环境用conda装也一样。conda install psutilPython版本方面psutil对Python 3.6以上都支持Python 3.8到3.12都能正常用。建议在实际环境里把版本升到最新老版本在部分新内核和Windows新版本上偶尔会出现兼容问题。装完后验证一下。import psutil print(psutil.__version__)输出的版本号大于5.8基本就是比较新的版本了。注意Windows平台上如果psutil是从源码安装需要编译C扩展但用pip安装的都是预编译好的wheel包不需要本地编译环境直接装完就能用。2.2 首次运行感受一下打开Python交互环境跑几个最基本的调用以最快速度建立直观感受。import psutil # 系统启动时间返回时间戳 print(psutil.boot_time()) # 物理CPU核心数/逻辑核心数 print(psutil.cpu_count(logicalTrue)) print(psutil.cpu_count(logicalFalse)) # 内存总量与可用量 print(psutil.virtual_memory()) # 当前所有进程PID print(psutil.pids()[:10]) # 磁盘分区 print(psutil.disk_partitions())第一次跑这些代码你会明显感觉到psutil把系统底层那些原本藏在命令输出里的信息变成了干净整齐的Python对象。这一点就足够让你愿意继续深入。3. 系统信息采集实战3.1 CPU信息获取别踩时间片这个坑CPU使用率是监控系统最核心的指标但也是新手最容易用错的。直接放代码。import psutil # 逻辑CPU使用率一次返回整体百分比 print(psutil.cpu_percent(interval1)) # 每个逻辑CPU的使用率 print(psutil.cpu_percent(interval1, percpuTrue)) # CPU频率 print(psutil.cpu_freq()) # 平均负载仅Linux/macOS print(psutil.getloadavg())关键点在于interval参数。cpu_percent在做第一次调用时返回的是无意义的历史数据或者0.0因为psutil需要先采样一次基准值等一段时间后再采样一次才能计算差值。interval1就是间隔1秒采样两次算出来的才是精确值intervalNone则是以上一次调用为基准非阻塞地返回增量数据适合高频轮询。我实际用下来监控脚本里最稳的方案是启动时先调用一次psutil.cpu_percent(intervalNone)做预热之后在循环里每次调用都保证interval1。这样既能拿到精确值又不会在time.sleep之外额外阻塞太久。还有个细节cpu_percent返回的是“整段时间内CPU忙碌时间占总时间的比例”理解成一段路上的堵车比例就对了。如果你interval0.1采样的是一瞬间的状态数字跳动会非常大反而不利于判断趋势。做告警判断时建议结合1分钟、5分钟这样的滑动窗口来综合判断单点跳高不代表机器真的满了。格式化输出要注意一点cpu_percent返回普通float但cpu_times返回的是累计时间。cpu_times里的user、system、idle都是自系统启动以来的累计秒数算使用率时要自己求两次采样的差值再除以间隔比直接用cpu_percent复杂得多日常监控直接用cpu_percent就足够了。3.2 内存信息虚拟内存和物理内存你要分清内存这块的API相对简单但概念要搞清。import psutil mem psutil.virtual_memory() print(mem.total) # 物理内存总量 print(mem.available) # 可分配给新进程的内存 print(mem.used) # 已使用内存 print(mem.percent) # 使用百分比 swap psutil.swap_memory() print(swap.total, swap.used, swap.percent)很多刚开始用的人把virtual_memory().used当成“进程实际占用的内存总和”其实不太准确。Linux下的used是“已被分配出去的内存”包含缓存和缓冲区是缓存可以随时回收的不能简单等同于“真正被程序占满”。更可靠的参考指标是available它给出的才是“无需回收缓存就能直接分配给新进程的内存量”。判断一台机器“内存够不够”优先看available和percent不要死盯used。各字段格式上total、used、available这些值都是以字节为单位的整数需要自己除以1024**3换算成GB。percent则是直接用(usable/total)算出来的百分比不用你自己再去算一遍。swap_memory在有些容器环境里可能拿不到准确数值甚至可能报错因为容器里的/proc/meminfo并不一定包含完整的swap信息。容器里需要监控内存时优先看cgroup的限制而不是宿主机全局数据不然你看到的可用量可能是主机级的而不是容器实际能用的配额。3.3 磁盘、网络与电池看清底层数据流磁盘和网络是系统监控里最容易忽略但最容易出问题的两块。import psutil # 磁盘分区 for part in psutil.disk_partitions(allFalse): print(part.device, part.mountpoint, part.fstype) # 某个分区的使用情况 usage psutil.disk_usage(/) print(usage.total, usage.used, usage.free, usage.percent) # 磁盘IO io psutil.disk_io_counters() print(io.read_bytes, io.write_bytes, io.read_time, io.write_time)disk_partitions默认不返回cdrom和loop设备如果想把这些也扫出来就把allTrue传进去。在生产环境做磁盘监控时filter掉loop设备能少处理很多无用的输出。disk_usage的参数是路径给人最直观的用法是传/ 根目录或C:\Windows的C盘。这里有个小坑如果你传一个不存在的路径会直接抛FileNotFoundError。轮询监控时要做好异常处理。网络这块用起来更讲究。import psutil # 网卡IO net psutil.net_io_counters() print(net.bytes_sent, net.bytes_recv) # 每块网卡单独看 per_nic psutil.net_io_counters(pernicTrue) print(per_nic) # 网络连接列表 conns psutil.net_connections(kindtcp) for c in conns[:5]: print(c.laddr, c.raddr, c.status, c.pid) # 网卡地址信息包括IP和MAC addrs psutil.net_if_addrs() print(addrs)net_io_counters返回的是累计流量不是实时速率。想看实时速率必须两次采样求差再除以间隔思路和CPU使用率的计算方式完全一致。net_connections这个API在高权限下才能看到全部连接普通用户下只能看到本用户进程的连接。在Windows上尤其明显不管理员权限运行会直接抛AccessDenied异常。做进程级网络监控时建议用管理员权限运行脚本或者干脆用root否则你拿到的连接列表缺胳膊少腿排查问题时的判断容易出错。值得留意的是循环采集net_io_counters时首次调用和第二次调用之间间隔不要太短最低在1秒左右。间隔太短的话两次采样的差值会很小除以时间后计算出的速率波动非常大显示出来的数值不平稳对判断带宽是否跑满没有帮助。传感器部分相对小众但真实场景里很有用。import psutil # 温度Linux/macOS下常见 temps psutil.sensors_temperatures() print(temps) # 风扇转速 fans psutil.sensors_fans() print(fans) # 电池状态笔记本上会用到 battery psutil.sensors_battery() if battery: print(battery.percent, battery.power_plugged)温度这类的传感器数据在台式机和服务器上不一定能拿到取决于硬件和驱动拿不到时返回空字典做好判断就行了。sensors_battery是笔记本电脑专属如果跑在桌面机上返回None同样要做空值防护。4. 进程管理从查进程到定位问题4.1 进程遍历与筛选psutil的进程管理能力比常规的os模块要强太多。os只能拿pid和简单的信息psutil能拿到进程的CPU使用率、内存占用、打开的文件、网络连接、父进程、子进程、启动命令行一个进程能挖的底裤全都能翻出来。import psutil for proc in psutil.process_iter([pid, name, username]): print(proc.info)process_iter配合attrs参数是最推荐的遍历方式。直接指定需要的字段psutil内部会优化采集逻辑避免每个进程都创建一个完整Process对象再来回查询批量遍历时的性能会好很多。如果你有明确的pid直接创建Process对象查详细信息。import psutil p psutil.Process(1234) print(p.name()) print(p.status()) print(p.cpu_percent(interval1)) print(p.memory_info().rss) print(p.cmdline()) print(p.create_time()) print(p.ppid()) print(p.children())这段代码会输出进程的名称、状态、CPU占用、实际物理内存rss单位字节、启动命令、父进程、子进程。排查问题时这几乎就是一份完整的“人物卷宗”。需要注意Process对象的构造不会立刻校验pid是否存在只有访问属性或调用方法时才可能会抛NoSuchProcess异常。写监控脚本一定要兜住这个异常不然进程退出后脚本会突然报错。4.2 定位高CPU进程的实战脚本下面是这段内容里最有实用价值的部分。生产服务器CPU飙高最头疼的不是“有多高”而是“谁造成的”。写一个脚本每秒采集一次所有进程的CPU和内存排序输出Top 10。import psutil def main(): procs {} for p in psutil.process_iter([pid, name, cpu_percent, memory_percent]): procs[p.info[pid]] p.info # 立即采集一轮做基准 for proc in psutil.process_iter([pid, name, cpu_percent, memory_percent]): p psutil.Process(proc.info[pid]) try: p.cpu_percent(intervalNone) except (psutil.NoSuchProcess, psutil.AccessDenied): pass while True: results [] for pid, info in procs.items(): try: p psutil.Process(pid) cpu p.cpu_percent(intervalNone) mem p.memory_percent() results.append((info[name], pid, cpu, mem)) except (psutil.NoSuchProcess, psutil.AccessDenied): continue results.sort(keylambda x: x[2], reverseTrue) for name, pid, cpu, mem in results[:10]: print(f{name:20s} pid{pid:7d} cpu{cpu:6.2f}% mem{mem:6.2f}%) time.sleep(1)脚本的逻辑关键在第一次遍历的预热。process_iter中带上cpu_percent属性第一次采集时psutil会记录每个进程的基准时间之后在循环里再调用cpu_percent(intervalNone)拿到的是相对上次采样的增量值。这个过程与单个进程的cpu_percent用法本质相同但放在循环里省事很多。加了time.sleep(1)控制轮询节奏整个脚本的额外开销非常低。把它们放大到几十台机器或者上千个进程的环境里这套代码的逻辑同样成立不至于把被监控的机器本身搞崩。实际操作中发现一个小经验直接使用psutil.process_iter不传attrs时每个进程对象在interator期间会自动缓存ins信息但在process_iter返回迭代器时进程可能已经退出了可能导致报错或者拿到的信息不完整。所以遍历时尽量显式传attrs参数并且在单进程操作里用try包住关键异常。4.3 进程启停与资源限制psutil不仅能“看”进程还能对进程做操作。import psutil p psutil.Process(pid) # 终止进程 p.terminate() # 强制杀掉 p.kill() # 等待进程退出最多等3秒 p.wait(timeout3) # 暂停/恢复进程 p.suspend() p.resume()terminate和kill的区别是前者发送SIGTERM让进程优雅退出进程还有机会清理资源和保存状态后者直接SIGKILL操作系统层面强制结束没有清理的机会。日常排查问题先用terminate等3秒看进程是否退出没退再用kill这是标准的“先礼后兵”。进程会创建子进程操作某个进程时如果不小心把父进程杀了子进程可能会变成“孤儿进程”继续运行。psutil里需要递归操作子进程时用children(recursiveTrue)拿到全部后代在kill前先处理子进程列表或者把整个进程组来一遍。还有个实用的接口可以设置进程优先级只在类Unix平台有效用nice值调整进程调度优先级。不过生产环境里改进程优先级要特别谨慎稍有不慎影响业务调度。5. 综合案例5分钟自研一套实时系统监控小程序光说不练假把式把前面的内容组合起来做成一个完整的案例。这个案例的目标是做一个命令行下的文本监控面板每秒刷新显示机器关键指标同时能按CPU占用排序显示Top5进程。整个过程不需要任何第三方UI库纯psutil加print就能完成。import time import os import psutil def format_bytes(n): if n 1024: return f{n} B units [KB, MB, GB, TB] for unit in units: n / 1024 if n 1024: return f{n:.2f} {unit} return f{n:.2f} PB def main(): # 预热CPU采集 psutil.cpu_percent(intervalNone) pids_cache {} try: while True: os.system(cls if os.name nt else clear) # 系统整体信息 cpu psutil.cpu_percent(interval1) mem psutil.virtual_memory() net1 psutil.net_io_counters() time.sleep(0.5) net2 psutil.net_io_counters() interval 0.5 up time.time() - psutil.boot_time() up_h int(up // 3600) up_m int((up % 3600) // 60) print(fCPU使用率: {cpu:6.2f}%) print(f内存: {format_bytes(mem.used)} / {format_bytes(mem.total)} ({mem.percent:.1f}%)) print(f网络: 发送 {format_bytes((net2.bytes_sent - net1.bytes_sent) / interval)}/s f接收 {format_bytes((net2.bytes_recv - net1.bytes_recv) / interval)}/s) print(f运行时间: {up_h}小时{up_m}分钟) # Top 进程 top [] for p in psutil.process_iter([pid, name]): try: proc psutil.Process(p.info[pid]) c proc.cpu_percent(intervalNone) m proc.memory_percent() top.append((p.info[name], p.info[pid], c, m)) except (psutil.NoSuchProcess, psutil.AccessDenied): continue top.sort(keylambda x: x[2], reverseTrue) print(\nTop 5 进程按CPU:) for name, pid, cpu, mem_p in top[:5]: print(f {name[:30]:30s} pid{pid:6d} cpu{cpu:6.2f}% mem{mem_p:6.2f}%) time.sleep(0.5) except KeyboardInterrupt: print(\n监控已退出。)这个脚本的核心逻辑在于“先采样再计算差值”CPU用预热轮询方式网络IO用两次流量差值换算速率。clear指令在Windows和Linux上不同用os.name做分支是跨平台运行干净利落的方式。整体结构可以拿来直接改造成告警工具比如把指标超过阈值就发通知的逻辑填进去。这个监控面板跑起来以后第一眼看到的东西就是系统的整体健康状态简单直接配合下来处理线上故障时很有参考价值尤其在没有任何基础设施监控工具的公司里这一段代码就是“五毛钱监控”的核心。我把整个案例的读取逻辑拆开讲解后你应该已经发现psutil在进程管理领域表现出来的信息收集能力远不止“模式化的系统接口”那么简单。它通过一套统一的API把系统的真实状态暴露到了Python的变量空间里这比任何在命令行里复杂拼装的工具都更贴近程序化开发。6. 常见问题排查与避坑心得6.1 进程采集报错psutil在实际运行中最常见的异常就是NoSuchProcess、AccessDenied和TimeoutExpired。异常触发场景处理方法NoSuchProcess进程在采集间隙退出了catch掉异常并跳过AccessDenied权限不足看不到别的用户进程信息用管理员/root权限运行TimeoutExpiredwait设置超时后进程没退出检查进程死活做兜底逻辑这个表初看简单但实际项目里很多人漏掉了异常处理导致监控脚本动不动自己崩了。反过来权限引发的问题往往是最容易被低估的。默认情况下普通用户访问系统级进程的详细信息在Linux上能看到但拿不到部分指标在Windows上会直接抛异常如果你的监控脚本需要覆盖全系统的进程务必用管理员权限运行。6.2 CPU和网络速率的计算容易错cpu_percent和net_io_counters都是“快照型”接口它们的返回值是累计值或相对值直接拿来做展示没问题但算速率时务必做差值计算。很多人在net_io_counters上犯的错误是只调用一次就拿bytes_sent除以时间实际上这个值是自开机以来的累计流量不是每秒速率。正确做法是两次采样后(第二次值 - 第一次值) / 时间间隔。一起配合使用的时候CPU百分比也可以用同样思路做直接用cpu_percent内部机制不用自己算差值。但如果你要算的是“某进程在某个时间段的平均CPU”那就要两次采样再取平均了。6.3 轮询循环里防止误伤主程序写高频轮询时time.sleep(1)基本是底线再快没有任何意义反而消耗系统资源。实测每秒轮询一次全系统进程信息在普通8核机器上额外占用的CPU不到2%。但要注意采集线程如果跑在业务进程里而采集代码出错导致线程阻塞主业务流程也会受影响。稳妥做法是把监控逻辑单独放到一个线程或者独立进程别和核心业务代码搅在一起。6.4 感知虚拟机和容器环境的限制在Docker容器、虚拟机、云主机上psutil读取到的是宿主机一层的资源还是容器实际配额取决于运行环境。比如容器内看到的内存可能是宿主机全局的内存而不是容器cgroup限制的内存磁盘IO、网络IO也有类似问题。做容器环境监控时需要读取/sys/fs/cgroup 下的相关文件来补充精确的数据不能完全依赖psutil返回的值。6.5 让指标更耐看的两个小技巧cpu_percent在进程刚启动时第一次调用返回值不可靠最好预热后再显示网络速率数值跳动很大时可以对最近几次采样求滑动平均值曲线会平滑得多内存使用率建议用available作为分子而不是total这样更能反映系统真实压力这些细节看着小但正是它们决定监控数据是“能动的数字”还是“有效的信号”。我在多个项目里实践下来凡是直接用原始数值做告警的误报率都高凡是做了平滑和预热处理的告警准确度明显提升。7. 两年用下来的心得与一点后续思路我现在基本所有运维工具都建立在psutil上从简单的单机监控脚本到批量机器信息采集再到进程异常定位这套库确实帮了大忙。用psutil最大的感受是它把“知道系统发生了什么”这件事的门槛直接拉低到了“写一段普通Python”的level。唯一要提醒的是psutil是工具而不是智能诊断系统它能给你进程的CPU、内存、网络数据但它们之间的关系能承载多大的因果推理取决于你对业务上下文的理解。拿到“某个进程CPU高”这个结果后定位是代码死循环还是数据库连接暴增仍需你手动去查日志和调用链。后续思路也很开放如果你们公司没有成熟的监控平台我这个脚本能改造成告警机器人把指标超过阈值的情况推送到告警群也可以把采集到的历史数据落到数据库做一个简单的时序趋势图还可以用psutil的进程管理能力写一个“异常进程自动降级/重启”组件让基础自愈成为可能。最后再分享一个小技巧在你所有用psutil的监控脚本里养成启动时打印psutil.__version__的习惯。系统环境一变这个版本号能救命。多平台部署的时候用try包住所有关键API调用宁可返回空值也不要让监控脚本自己先挂掉。这套工具值得你在每个Python项目里备着。