根本原因是gopsutil采样接口默认不触发真实读取：cpu.percent()需传非零duration（如time.second）才发起系统调用，mem.virtualmemory()仅返回单次快照；进程对象不自动刷新，须新建实例并立即调用指标方法。
用 gopsutil 采集进程指标时，为什么 CPU 和内存总是 0？
根本原因是 gopsutil 的采样接口默认不触发真实读取——它只是返回缓存或初始零值。比如 cpu.Percent() 必须传入非零 time.Duration（如 time.Second）才会发起一次系统调用采样；mem.VirtualMemory() 返回的是单次快照，不带历史对比逻辑。
-
cpu.Percent(time.Second)才是有效调用，漏传参数会导致永远返回[]float64{0} -
process.NewProcess(pid)后必须立刻调用cpuPercent()和memoryInfo()，不能复用旧实例——进程对象内部不自动刷新 - 在容器环境里监控宿主进程时，
disk.Usage("/path")可能因挂载命名空间隔离失败，得先用disk.Partitions(true)查真实挂载点 -
host.Info()依赖/etc/os-release，Alpine 镜像里默认缺失，会 fallback 到空字符串，别直接用它做判断依据
监控多个进程时，goroutine 泄露和信号竞争怎么避免？
每个进程单独起 goroutine 轮询看似自然，但若没统一生命周期管理，程序退出时 goroutine 会残留；同时 SIGINT/SIGTERM 若未同步阻塞所有监控循环，可能部分 goroutine 在重启命令执行中途被杀，导致状态不一致。
- 用
context.WithCancel()创建父 context，所有监控 goroutine 启动时接收该 context，并在select中监听ctx.Done() - 重启命令（如
exec.Command("systemctl", "restart", "xxx")）必须加cmd.Run()并检查 error，否则 shell 命令可能静默失败 - 不要在 goroutine 内直接调用
os.Exit()，应通过 channel 通知主 goroutine 统一退出 - 对同一进程 PID 的并发访问（如多次调用
p.MemoryInfo()）无需额外锁，gopsutil内部已处理，但自定义状态缓存（如上次 CPU 值）需用sync.Mutex
告警触发后执行重启，为什么有时失败或重复执行？
常见于阈值抖动场景：CPU 瞬间冲高又回落，若每轮都无条件触发重启，会造成服务反复震荡；另外，重启命令本身可能因权限、路径或依赖未就绪而失败，但监控模块没做失败重试或抑制，导致问题恶化。
- 引入“稳定窗口”机制：连续 N 次采样（如 3 次 × 5 秒间隔）均超阈值才触发动作，避免瞬时毛刺干扰
- 重启命令执行前，先用
exec.Command("pgrep", "-f", "your_service_name")确认进程是否真已退出，避免重复 kill - 记录最近一次告警时间戳，10 分钟内同进程 ID 不重复告警，防止雪崩
- 把重启命令包装成可重试函数，最多尝试 2 次，每次间隔 2 秒，并将 stderr 输出写入日志供排查
如何让监控模块不侵入主业务逻辑？
核心是分离关注点：监控模块只负责发现异常、发信号、执行预设动作；业务进程不该感知自己被看管，更不该为监控加 health check 接口或埋点。
- 用独立二进制部署，例如
procmon --config config.json，配置文件里声明要监控的进程名、PID 文件路径、阈值和重启命令 - 避免用
syscall.Kill()直接杀进程，优先走 systemd 或 supervisor 的标准接口（如systemctl restart），保持信号语义一致 - 监控模块自身也应支持优雅退出：收到 SIGTERM 后等待所有 goroutine 清理完毕再退出，避免中断正在执行的重启流程
- 日志输出用结构化 JSON，字段含
"pid"、"triggered_at"、"action"，方便后续接入 ELK 或 Loki 做聚合分析
gopsutil 的 syscall 开销会明显上升；建议默认 5 秒采样一次，高频场景再按需调整。另外，所有路径（如 PID 文件、重启脚本）务必用绝对路径，相对路径在 daemon 模式下极易失效。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
