用 top 定位高 cpu 进程需按 1 键看单核负载、h 键切线程视图，再用 ps -t -p 查高 %cpu 的 tid 对应线程名；容器中 tid 是宿主机 pid；日志需用 logger 或配置 standardoutput=journal 才进 journalctl。
怎么用 top 快速定位吃 CPU 的进程，而不是被平均值骗？
top 默认显示的是所有 CPU 核心的加权平均负载，但真实问题往往藏在单个线程里。比如一个 Java 应用突然卡住，top 显示 CPU 使用率才 30%，其实是因为它跑了 8 个核，某个线程占满 1 个核（12.5%），其余空闲——你根本看不出异常。
- 按
1键展开各 CPU 核心使用率，看是否某核长期 95%+ - 按
H键切换线程视图（Threads mode），找出%CPU列里持续高于 80 的TID - 记下那个
TID，用ps -T -p <pid></pid>查它属于哪个线程名，再结合应用日志定位逻辑 - 注意：容器环境里看到的
TID是宿主机命名空间下的，不是容器内 PID
systemd-journald 日志查不到告警触发记录？先确认这三件事
很多监控脚本（比如用 curl 调 webhook）失败了，翻 journalctl 却没痕迹，不是日志丢了，是输出没进 journal。
- 确保脚本执行时用了
logger命令打点，比如：logger "alert: disk usage >90%"，直接echo到终端或文件不会进 journal - 如果是 systemd service，检查
StandardOutput=journal和StandardError=journal是否显式配置，否则子进程 stdout/stderr 会被丢弃 -
journalctl -u <service-name> --since "2 hours ago"</service-name>比-b更可靠，因为告警可能跨 boot
写 shell 告警脚本时，df 和 statfs 返回的磁盘使用率为什么对不上？
df -h 显示 92%，但用 du -sh /var/log 加总才 60GB，怀疑工具不准——其实是两者统计维度不同。
韩顺平PHP入门到精通全套笔记
下载
韩顺平，毕业于清华大学，国内著名的软件培训高级讲师，先后在新浪、点击科技、用友就职。 主持或参与《新浪邮件系统》、《橙红sns(社会化网络)网站》、《点击科技协同软件群组服务器端(Linux/solaris平台)》、《国家总参语音监控系统》、《英语学习机系统》、《用友erp(u8产品)系统》等项目。实战经验丰富，授课耐心细致，通俗易懂，勇于实践，勤于创新，授课风格贴近生活，授课语言生动风趣，多年
-
df看的是文件系统级剩余空间，包含 reserved blocks（默认 5%，root 用户可用，普通用户不可见） -
du只统计当前用户有权限读取的文件大小总和，不包括删除但未释放的文件（lsof +L1才能发现） - 真实告警阈值建议按
df -P | awk '$5 ~ /%$/ {sub(/%/,"",$5); if($5 > 85) print $1,$5}'，但必须配合lsof +L1定期扫一遍，否则删了日志却因进程没重启，空间不释放
用 netstat 或 ss 查连接数时，TIME_WAIT 突然暴涨，是不是要调 net.ipv4.tcp_tw_reuse？
不是所有 TIME_WAIT 都需要干预。它本身是 TCP 正常挥手的一部分，大量存在只说明短连接频繁——先判断是不是真问题。
- 先跑
ss -ant | awk '{++s[$1]} END {for(i in s) print i, s[i]}'，确认是不是TIME_WAIT真的占绝对多数（比如 >80%） - 如果是后端服务被上游高频轮询，优先改上游重试策略或切长连接，而不是动内核参数
-
net.ipv4.tcp_tw_reuse在 NAT 环境下慎开，可能引发连接混淆；更安全的做法是缩短net.ipv4.tcp_fin_timeout（从 60 降到 30）并确保net.ipv4.ip_local_port_range足够宽（比如1024 65535）
实际部署时，最常漏掉的是告警脚本自身的资源泄漏：比如用 while true; do ... sleep 60; done 跑着，但里面忘了 unset 临时变量，几周后 Bash 进程 RSS 涨到 200MB，反而把监控搞挂了。
