服务器监控如何监控容器运行时的退出事件

直接监听 Docker Engine 事件流是最轻量及时的方式，通过 docker events 过滤 die/oom 事件并结合 inspect 判断 OOMKilled 和退出码，实现精准根因分析与告警响应。

直接监听 Docker Engine 的事件流，是最轻量、最及时的方式。它不依赖轮询或日志解析，而是由守护进程主动推送状态变更，天然适配容器“短生命周期”的特性。

用 docker events 实时捕获退出事件

Docker 提供原生事件接口，可精准过滤 die（容器终止）和 oom（内存溢出）事件：

docker events --filter 'event=die' --filter 'event=oom' --format '{{json .}}' | while read event; doecho "$event" | jq -r 'select(.Actor.Attributes.name) | "(.time) (.Actor.Attributes.name) exited with (.Actor.Attributes.exitCode // "unknown")"' >> /var/log/container-exit.logdone

该脚本会持续输出类似：

2026-08-13T14:22:05.123 web-api exited with 137

关键点：

1. --filter 'event=die' 捕获所有容器终止事件（无论原因）
2. --filter 'event=oom' 单独捕获内核 OOM 杀死事件（部分版本需配合 --filter 'type=container'）
3. jq 提取容器名、时间、退出码，便于后续分析或告警

结合 exitcode 和 OOMKilled 字段做根因判断

仅靠事件不够，需进一步确认是否真因内存溢出：

# 查看某容器最新退出详情docker inspect <container_id> | jq '.State | {ExitCode, OOMKilled, FinishedAt}'# 示例输出：# {# "ExitCode": 137,# "OOMKilled": true,# "FinishedAt": "2026-08-13T14:22:05.123Z"# }

退出码 137 + OOMKilled: true 是 OOM 的铁证；若 OOMKilled: false 但 ExitCode 为 1，则大概率是应用崩溃。

对接告警与自动响应

事件流可直接接入通知链路：

1. 推送到 HTTP 告警服务（如前面提到的 curl -X POST）
2. 写入本地文件后由 Filebeat 收集进 ELK
3. 通过 grep -q "exitCode":137" 触发重启脚本（谨慎用于关键服务）

补充：避免漏掉已退出容器的离线诊断

对已停止容器，用以下命令快速回溯：

# 查看最近 10 个退出容器的退出码和 OOM 标记docker ps -a --format "{{.ID}}t{{.Status}}t{{.Names}}" --filter "status=exited" | head -10 | while IFS=$'t' read id status name; docode=$(docker inspect "$id" --format='{{.State.ExitCode}}' 2>/dev/null)oom=$(docker inspect "$id" --format='{{.State.OOMKilled}}' 2>/dev/null | tr '[:lower:]' '[:upper:]')echo -e "$namet$codet$oomt$status"done | column -t

输出示例：

api-gateway137TRUE Exited (137) 2 minutes ago

这种方式不依赖实时监听，适合巡检或故障复盘。

本质上，监控退出事件不是“查结果”，而是“等信号”——Docker daemon 就是那个最可信的信使。