一台开发机也值得有晨检

很多同学的 Linux 开发机上同时跑着数据库、缓存和几个试验容器。编排平台的告警还没接上时，最省事的办法不是再装一套监控，而是每天用一段很短的 Python 问 Docker 三个问题：谁在跑，谁异常退出，谁在反复重启。

只问三个问题

第一，当前运行中的容器有哪些。第二，已经退出的容器里，哪些退出码不是 0。第三，有没有容器的重启次数在悄悄增加。这三个问题覆盖了早上看终端时最常见的意外。一次性任务容器（名字里常带 job 或 migrate）本来就会正常退出，要和长期服务分开，否则每天都会被误报打扰。

为什么不用一长串 shell

管道能很快拼出结果，但要按状态分组、把时间换成易读的本地描述、再把超长名字截断，引号和 awk 会越来越难改。Python 用 subprocess 以参数列表调用 docker，不经过 shell 拼接，超时也可以单独设置，docker daemon 卡住时脚本不会一直挂着。处理逻辑就是普通字符串，和日常写的小工具同一习惯。

最小步骤

1. 使用 docker ps -a 的自定义格式输出，每行只保留名称、状态、退出码和重启次数。固定列比解析默认表格稳。
2. 分成 running、exited、restarting 三组。
3. exited 里退出码非 0 的单独列出；名字像一次性任务的归到「预期退出」。
4. 打印几行中文摘要，例如：运行中 6 个，异常退出 1 个，名称是 demo-redis。
5. 需要留档时，把同一段文字追加到本机日志，并在开头写上日期。不要把日志写进容器内部，宿主机重启后容器可重建，日志会丢。

容易看错的状态

状态列里的 Up 3 hours 只说明这一次启动后活了多久，不代表中间没有重启。重启次数要单独取字段，不能只看 STATUS。Compose 启动的容器名字里带项目前缀，报告里保留前缀，比只留服务名更容易对上目录。权限上，把运行脚本的用户加入 docker 组，比在定时任务里写 sudo 更干净；改组之后需要重新登录才生效。

和辅助补全的边界

写脚本时可以用编辑器补全生成参数解析和日志格式，但状态字段的含义要自己对着 docker inspect 核对一遍。模型常把退出码 0 一律当成健康，这会把正常结束的迁移任务和真正在提供服务的进程混在同一条告警里。判断规则留在自己确认过的几行里，比把整段输出交给模型总结更稳。

小结

开发机不需要先上完整可观测栈，才能知道容器是否老实。固定格式的容器列表、一段不到百行的 Python、以及把一次性任务和长期服务分开，就够做每天一次的晨检。等这份短报告开始反复出现你关心的异常，再接入集中日志也不迟。