应优先使用 /proc/loadavg 而非 uptime 监控负载，因其格式固定、不受 locale 和终端影响；用 awk '{print $1,$2,$3}' 提取三值，结合时间戳落盘分析趋势，重点关注 5/15 分钟值与 cpu 核心数的关系及长期缓慢爬升。
怎么用 watch 实时观察负载变化
直接用 watch 是最简单的方式，但默认刷新不带时间戳、不记录历史，容易漏掉瞬时峰值。别只跑 watch uptime 就完事。
- 加
-n 2控制间隔（2 秒比默认 2 秒更明确，避免误解） - 用
uptime | awk '{print $10, $11, $12}'提取负载三值，避开 locale 导致的字段漂移（比如中文系统里 “up” 变成 “已运行”，$10就错位） - 想留痕？改用
watch -n 2 'echo "$(date +%s) $(awk "{print \$1,\$2,\$3}" /proc/loadavg)" >> /tmp/load.log'，时间戳用秒级整数，方便后续用awk或 gnuplot 绘图
为什么 /proc/loadavg 比 uptime 更适合监控变化
/proc/loadavg 是内核原始输出，格式固定五列，前三个就是 1/5/15 分钟负载，不会受终端宽度、用户数、语言环境影响。而 uptime 输出是字符串拼接，字段位置浮动——尤其在 busybox 环境或容器里，awk '{print }' 很可能取错。
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 脚本中一律用
awk '{print $2}' /proc/loadavg取 5 分钟值，这是日常巡检最稳的参考点 - 第四字段（如
2/124）斜杠前的数字是当前就绪+D状态进程数，比平均值更实时，适合做秒级告警：如果它持续 > CPU 核心数 × 1.5，说明排队已形成 - 注意：
/proc/loadavg权限是-r--r--r--，普通用户可读，不用sudo
如何判断负载是在爬升还是只是毛刺
单看某一时刻的 1 分钟值没意义。真正要盯的是 5 和 15 分钟值的趋势差，以及它们和 CPU 核心数的关系。
- 执行
grep -c 'processor' /proc/cpuinfo先确认逻辑核数，假设输出是4 - 如果
awk '{print $2,$3}' /proc/loadavg返回3.8 3.1→ 5 分钟值 > 15 分钟值，说明压力在加重 - 如果返回
0.9 2.1→ 15 分钟值反超，说明刚过去的峰值正在衰减，大概率是临时任务 - 再查
ps -eo stat,pid,comm | grep " D "，若结果非空，且iostat -x 1中%util接近 100%，那爬升根源在 I/O，不是 CPU
长期趋势怎么存、怎么看
靠人工盯 watch 不现实。真要分析变化，得落盘 + 定期采样。
- 别用
top -b -n1，它开销大、输出不稳定；优先用cat /proc/loadavg配合date +%s - 写个最小化循环：
while true; do echo "$(date +%s) $(cat /proc/loadavg | awk '{print $1,$2,$3}')"; sleep 60; done >> /var/log/load-history.log - 日志文件每行是 “时间戳 1min 5min 15min”，用
awk '$2 > 4 {print $1}' /var/log/load-history.log就能快速定位所有超载时刻 - 最容易被忽略的一点：很多团队把 1 分钟值当趋势指标，结果错过缓慢爬升——15 分钟值连续 3 小时 > 核心数 × 0.8，比单次 1 分钟冲到 5 更危险
