docker容器启动失败需依赖外部机制实现告警闭环：通过docker events监听die事件、healthcheck配合巡检、或swarm/k8s原生事件监控，最终统一调用钉钉等通知通道，建议增加去重。

当 Docker 容器启动失败时，Docker 本身不会自动发送告警，需要借助外部机制实现“失败→检测→通知”闭环。核心思路是：监听容器状态变化或检查启动结果，并在失败时调用邮件、Webhook、钉钉/企业微信等通知渠道。

监听容器事件并过滤启动失败

Docker 提供 docker events 实时流式输出容器生命周期事件。可结合 grep 和 awk 筛选 die（异常退出）或 start 后紧随 die 的组合行为，间接识别启动失败（如因配置错误、端口占用、镜像缺失导致秒退）。

• 运行后台监听脚本：
  docker events --filter 'event=die' --format '{{.Actor.Attributes.name}} {{.Status}} {{.TimeNano}}' | while read line; do echo "[FAIL] $line" | send-notify.sh; done
• 更精准做法：记录 start 时间戳，5 秒内若同容器 ID 出现 die，则判定为启动失败（需简单状态缓存，可用临时文件或 Redis）

使用 healthcheck + 外部巡检触发告警

在 Dockerfile 或 docker-compose.yml 中定义 HEALTHCHECK，让容器启动后主动上报健康状态。再用独立脚本定期调用 docker inspect --format='{{.State.Health.Status}}' container_name 检查，非 healthy 即告警。

• 示例健康检查：
  HEALTHCHECK --interval=10s --timeout=3s --start-period=30s --retries=3 CMD curl -f http://localhost:8080/health || exit 1
• 巡检脚本每 15 秒执行一次，连续 2 次返回 unhealthy 或 starting 超时，即触发通知

集成容器编排工具的原生告警能力

若使用 Docker Swarm 或 Kubernetes，优先利用其内置机制：

• Docker Swarm：用 docker service logs + journalctl -u docker 监控 manager 节点日志，捕获 task failed、no such image 等关键词
• Kubernetes：直接通过 kubectl get events --field-selector reason=FailedCreate,reason=BackOff 获取 Pod 创建失败事件，配合 kube-event-exporter 推送至 Alertmanager

统一通知通道配置（以钉钉为例）

所有检测逻辑最终调用同一通知函数，避免重复编码。推荐封装为 shell 函数或轻量 HTTP 服务：

• 钉钉机器人需开启「自定义关键词」（如 “Docker 启动失败”），并在请求 body 中包含该词
• cURL 示例：
  curl -H "Content-Type: application/json" -d '{"msgtype": "text", "text": {"content": "⚠️ 容器 web-app 启动失败，原因：port 8080 already in use"}}' https://oapi.dingtalk.com/robot/send?access_token=xxx
• 建议增加通知去重（如 5 分钟内相同容器名失败只发一次），防止刷屏