容器异常退出需结合日志、状态和退出码综合判断，通过docker events监听die事件并过滤非零退出码触发告警，辅以定时巡检兜底，按退出码分级通知（如137→OOM立即告警，143→不告警），并关联日志关键词提升准确性。
容器异常退出本身不是直接可告警的“指标”，而是需要结合日志、状态变化和退出码综合判断的故障信号。docker 原生不提供退出事件的主动推送告警，必须通过外部监控体系捕获并触发通知。
监听容器退出事件并触发告警
Docker 守护进程支持事件流（docker events），能实时捕获 die 事件（即容器终止）。这是最及时、最轻量的退出感知方式。
- 运行后台监听脚本，过滤
status=die且非预期退出的容器（如非ExitCode=0） - 提取容器名、镜像、退出码、时间戳等关键字段
- 匹配预设规则（例如：退出码为 1、137、143；或特定服务容器频繁 die）后调用告警接口（Webhook/邮件/钉钉）
示例命令监听（可放入 systemd service 中长期运行）：
docker events --filter 'event=die' --format '{{.ID}} {{.Status}} {{.Actor.Attributes.exitCode}} {{.Time}}' | while read id status code ts; do [ "$code" != "0" ] && echo "ALERT: $id died with code $code at $(date -d @$((ts/1000000000)) 2>/dev/null)" | curl -X POST -H 'Content-Type: application/json' -d '{"msg":"'"$id"' died, exit $code"}' https://your-webhook-url; done
基于 docker ps -a 和定时巡检的补充告警
事件监听可能丢失（如 daemon 重启期间），建议搭配定时扫描作为兜底。
- 每分钟执行：
docker ps -a --filter "status=exited" --format "{{.ID}} {{.Status}} {{.Names}} {{.Command}}" | grep -v "Exit (0)" - 对输出结果去重、统计频次（如某容器 5 分钟内退出 ≥2 次即告警）
- 避免误报：排除已知一次性任务（如 cron job 容器），可通过标签识别：
--filter "label=type=job"
关联退出码做根因分级告警
不同退出码代表不同严重程度，应差异化通知：
- 137 → 内存超限（OOMKilled）→ 立即通知运维+扩容提醒
- 143 → 收到 SIGTERM（正常关闭或被 stop）→ 可仅记录，不告警
- 1 或空码 → 应用启动失败或崩溃 → 通知开发查日志
-
其他非 0 码 → 查看
docker inspect中State.Error字段补充上下文
集成日志 + 退出状态的联合判断
单看退出不够，需结合最后几行日志确认是否真异常：
- 在发现 exited 容器后，立即执行
docker logs --tail 20 <id> - 匹配关键词如
"panic"、"OutOfMemoryError"、"connection refused" - 若同时满足“非零退出码 + 关键错误日志”，提升告警优先级并附带日志片段
