Golang读取Procfs获取进程IO信息

Go 直接读取 /proc/[pid]/io 是最轻量准确的进程 IO 统计方式，需用 bufio.Scanner 解析文本，提取 rchar、wchar、read_bytes、write_bytes、cancelled_write_bytes 5 个关键字段，注意权限、路径校验与缺失字段处理。

Go 如何从 /proc/[pid]/io 读取进程 IO 统计

直接读取 /proc/[pid]/io 是最轻量、最准确的方式——它不依赖外部工具，也不需要 ptrace 权限，只要进程存在且当前用户有读权限（通常是同一用户或 root），就能拿到原始 IO 计数。Go 没有内置封装，得自己解析文本格式。

常见错误是用 os/exec 调 cat 或 awk，既慢又不可靠；还有人误以为 runtime.ReadMemStats 或 debug.ReadGCStats 能反映磁盘 IO，其实它们只管内存和 GC。

• /proc/[pid]/io 是纯文本，每行形如 rchar: 123456789，冒号后带空格，末尾无换行符干扰
• 必须按行扫描，不能用 fmt.Fscanf 直接读整数——某些字段（如 cancelled_write_bytes）在旧内核可能不存在，跳过即可
• 推荐用 bufio.Scanner + strings.Cut（Go 1.18+）或 strings.SplitN(line, ":", 2) 安全分割，避免 panic
• 字段值是十进制字符串，用 strconv.ParseUint(..., 10, 64) 转，别用 atoi 或 int 强转——值可能超 int32

ReadProcessIO 函数该返回哪些字段

Linux procfs 的 io 文件定义了 9 个字段，但真正稳定可用、多数场景关心的只有 5 个：rchar、wchar、read_bytes、write_bytes、cancelled_write_bytes。其余如 syscr/syscw 是系统调用次数，不是字节数，容易误解。

注意：rchar/wchar 包含所有读写（含缓存、/dev/null、管道等），而 read_bytes/write_bytes 只统计实际落盘或从磁盘读取的字节数——这才是衡量磁盘压力的关键指标。

• rchar 和 wchar 增长快不代表磁盘忙，比如程序大量往 /dev/null 写，wchar 狂涨但 write_bytes 几乎不动
• cancelled_write_bytes 表示被截断或丢弃的写入量（如 page cache 回收时未刷盘的脏页），值持续上升说明写入压力大但落盘滞后
• 如果某个字段缺失（例如容器中 cgroup v2 环境下 cancelled_write_bytes 不出现），跳过即可，不要设默认 0——0 有语义（确认为零），缺失代表不可用

权限与路径检查不能省

Go 程序读 /proc/[pid]/io 失败，90% 是权限或路径问题，不是代码逻辑错。Linux 对 /proc/[pid] 目录做了严格权限控制：非 root 用户只能访问自己启动的进程，且 /proc/[pid]/io 在较新内核（5.10+）默认仅对 owner 和 root 可读。

典型错误现象：open /proc/12345/io: permission denied 或 no such file or directory（后者常因进程已退出，或 PID 传错）。

• 务必先检查 os.Stat("/proc/[pid]") 是否返回 nil 错误，再打开 io 文件——避免“文件不存在”掩盖真实权限问题
• 用 os.Getuid() 和 os.Stat 返回的 os.FileInfo.Sys().(*syscall.Stat_t).Uid 对比，确认是否是进程 owner（非 root 场景下必须）
• 路径拼接必须用 filepath.Join("/proc", strconv.Itoa(pid), "io")，别手拼斜杠——Windows 兼容性虽无关，但能防低级 typo
• 容器环境要注意：PID 是宿主机命名空间的，/proc 挂载点若被覆盖（如 procfs 未正确挂载），/proc/[pid]/io 就会失效

性能和并发读取的边界

单次读 /proc/[pid]/io 开销极小（通常 <100μs），但频繁轮询（如每 100ms 读一次）会导致大量 syscalls，尤其在监控数百进程时，open/read/close 三连会成为瓶颈。

更严重的是：procfs 是虚拟文件系统，读取时内核需实时聚合 per-task 的 IO 计数器，高并发读多个 PID 可能引发锁竞争（尤其在老内核上）。

• 不要为每个 PID 启一个 goroutine 去读——用单 goroutine 批量串行读，间隔至少 500ms，足够平衡精度与开销
• 如果需长期监控，优先考虑 netlink 或 eBPF（如 libbpfgo），procfs 只作 fallback 或调试用
• 读取前加 time.Sleep(1 * time.Millisecond) 无意义；但读完后缓存结果 200–500ms 再对外暴露，能平滑抖动
• 别把 /proc/[pid]/io 当做实时流——它本质是快照，两次读之间的差值才是速率，直接暴露绝对值没意义

procfs 的 IO 字段看似简单，但字段语义差异、权限边界、内核版本兼容性，都藏在细节里。最容易被忽略的是：你以为在看磁盘 IO，其实 rchar 和 read_bytes 差着一个 page cache 的距离。