崩溃循环先抓现场
服务反复重启时，自愈机制会把日志刷成噪音，最后一屏反而什么都看不出来。正确做法是先暂停自动重启，拿到崩溃瞬间的退出码与日志，再决定修复路径。让循环停下来，是排查的前提。
基本信息
| 处置顺序 | 先停自愈再抓现场 |
|---|---|
| 关键信息 | 退出码与最后一段日志 |
| 常见原因 | 内存被杀、应用异常、外部终止 |
| 记录项 | 重启次数与容器状态 |
| 恢复 | 确认原因后再放开自愈 |
典型使用场景
- 上线后服务反复重启
- 容器被内存限制杀掉
- 进程收到外部终止信号
- 排查「重启次数在涨但业务看着正常」
- 把崩溃现场（退出码、最后日志、时间点）记录到事故单里
取证
取证
systemctl status <服务> | head -30 # 看重启计数
docker inspect --format '{{.RestartCount}} {{.State.OOMKilled}}' <容器>
journalctl -u <服务> -n 200 --no-pager | tail -50
# 排查期间临时把重启策略收敛或停掉单元，避免刷屏与反复抢占 GPU退出码速查
| 退出码 | 常见含义 | 优先怀疑 |
|---|---|---|
| 137 | 被强制终止 | 内存不足或超时被杀 |
| 1 | 应用异常退出 | 看调用栈首段 |
| 143 | 收到终止信号 | 先查是谁在发信号 |
| 容器被杀 | 触发内存限制 | 核对容器资源限额 |
排查期间临时收敛重启策略：不这么做的话日志会被反复刷屏，还会反复抢占 GPU 资源，让同机的其它服务也受影响。
崩溃前的最后几行日志最有价值：把日志按实例与时间归档，避免被后续重启的输出覆盖。
退出码要结合容器状态一起看：被内存限制杀掉与收到终止信号，处理路径完全不同。
观察期至少覆盖一个完整流量周期：只在低峰观察通过的话，高峰才出现的问题可能完全没暴露。