17370845950

优先选 gopsutil 而非原生 syscall 或 /proc：它跨平台抽象了 Linux/cgroup v2、Windows/macOS 差异，但需注意 cpu.Percent() 必须传 time.Duration 才采样、disk.Usage() 在容器中需先用 disk.Partitions(true) 查真实挂载点、host.Info() 在 Alpine 中 fallback 到空字符串。

Go 语言写系统监控程序，核心不是“能不能”，而是“要不要自己造轮子”——gopsutil 已覆盖绝大多数场景，直接用它比手撸 /proc 解析或调用 sysctl 稳定得多。

为什么优先选 gopsutil 而不是原生 syscall 或 /proc

自己读 /proc/meminfo 或调用 runtime.ReadMemStats() 看内存，看似轻量，但很快会遇到：不同 Linux 发行版 /proc 字段顺序不一致、cgroup v2 下 /proc/cgroups 不再可用、Windows/macOS 完全不可用。而 gopsutil 在这些平台做了抽象和 fallback。

• gopsutil 的 cpu.Percent() 默认返回每核使用率，加 time.Second 参数才触发采样；漏传会导致返回全 0
• disk.Usage("/path") 在容器中可能因挂载命名空间隔离失败，需配合 disk.Partitions(true) 先查真实挂载点
• 它的 host.Info() 依赖 /etc/os-release，Alpine 镜像里默认没这个文件，会 fallback 到空字符串

采集 CPU/内存/磁盘时必须设对的参数

默认行为往往不是你想要的。比如 cpu.Percent() 不传 time.Duration 就不会真正采样，mem.VirtualMemory() 返回的是瞬时快照，不带历史趋势。

package main

import (
    "fmt"
    "time"
    "github.com/shirou/gopsutil/cpu"
    "github.com/shirou/gopsutil/mem"
    "github.com/shirou/gopsutil/disk"
)

func main() {
    // ✅ 正确：指定采样间隔，否则返回 []float64{}
    percents, _ := cpu.Percent(time.Second, false)
    fmt.Printf("CPU: %.1f%%\n", percents[0])

    // ✅ 正确：获取当前内存使用
    v, _ := mem.VirtualMemory()
    fmt.Printf("Me
m: %.1f%% used (%d/%d MB)\n", v.UsedPercent, v.Used/1024/1024, v.Total/1024/1024)

    // ✅ 正确：先找根分区，避免硬编码 "/"
    parts, _ := disk.Partitions(true)
    for _, p := range parts {
        if p.Mountpoint == "/" {
            du, _ := disk.Usage(p.Mountpoint)
            fmt.Printf("Disk /: %.1f%% used\n", du.UsedPercent)
            break
        }
    }
}

HTTP 暴露指标时别直接用 net/http 返回 JSON

裸写 http.HandleFunc + json.Marshal 看似简单，但会快速撞上三个问题：并发采集冲突（多个请求同时调 cpu.Percent()）、无超时控制（disk.Usage() 在 NFS 挂死时卡住整个 handler）、指标格式不兼容 Prometheus。

• 用 sync.Once 或 sync.RWMutex 保护采集逻辑，避免重复初始化或并发读写结构体
• 所有 gopsutil 调用必须包在 context.WithTimeout 里，例如 ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
• 如果后续要对接 Prometheus，直接用 prometheus.NewGaugeVec + promhttp.Handler()，别自己拼 /metrics 文本

容器环境下的常见失效点

在 Docker/K8s 里跑 Go 监控程序，gopsutil 默认行为会误判宿主机资源。关键不是“能不能运行”，而是“它读的是哪一层的视图”。

• 容器内执行 host.Info() 返回的是宿主机的 hostname 和 uptime，但 os.Getpid() 是容器 PID，混用会导致日志混乱
• process.Pids() 默认列出所有进程，包括宿主机的，需过滤 p.Pid > 0 && p.Pid （容器 PID 通常较小）或读 /proc/1/cgroup 判断是否在容器中
• 想查容器自身 CPU limit，得解析 /sys/fs/cgroup/cpu/cpu.cfs_quota_us，gopsutil 不提供该接口，必须手动读

真正难的不是采集数据，而是明确“这个值在当前运行环境中代表什么”。比如 cpu.Times(false) 返回的 user 时间，在容器里是受限于 cgroup 的，还是宿主机全局的——得看你是从 /proc/stat 还是 /sys/fs/cgroup/cpu/xxx/cpu.stat 读的。