7.3 事件监控与日志管理

7.3 事件监控与日志管理

本节摘要：无守护进程不等于无观测。容器日志经 conmon 直写 journald，可按容器名与服务名两条路径查询；podman events 提供镜像、容器、卷的生命周期事件流，支持过滤与订阅。本节讲两条日志路径的实操、事件流的典型用法，以及把它们接入系统级监控栈的思路——用 Linux 自己的观测设施看容器，而不是再养一个观测平台。

日志去哪了：journald 的两条查询路径

第 2.1 节讲过 conmon 的职责清单里有"日志转发"——它把容器主进程的标准输出与错误直接写进 journald。这意味着查询容器日志就是查询 journald，两条路径各有用途：

# 路径一：Podman 的封装（按容器查，习惯 Docker 的人最顺手）
podman logs web
podman logs --since 30m --tail 100 web
# 参数语义与 docker logs 一致——迁移期的肌肉记忆可以保留

# 路径二：journald 原生（按 systemd 身份查，服务化部署的正解）
journalctl --user -u web.service --since today
# 解读：按服务单元过滤。Quadlet 管理的容器日志天然带着
# 服务身份，重启、重建后日志仍归属同一单元——跨容器世代连续

# journald 路径的独门能力：关联查询
journalctl --user -u web.service -o verbose | grep -E "IMAGE|CONTAINER" | head -4
# 每条日志自带容器元数据（镜像 digest、容器 ID 等），
# 出问题时能直接对上"这是哪个镜像版本打的日志"
​

两条路径的分工建议：人肉调试用 podman logs（顺手），脚本与告警用 journalctl（单元身份稳定，容器重建后不用改查询条件）。日志轮转由 journald 的配额机制统一管理，不需要容器侧任何配置——这也是"复用系统设施"红利的具体形态。

Docker 侧的对照：dockerd 的日志驱动体系（json-file、journald、fluentd 等插件）配置在 daemon 层，切换要动 daemon；Podman 的日志路径写死走 journald（events_logger 另有选择），取舍是"少一个可配置项，多一分一致性"。如果你需要把日志再转给 ELK 类平台，在 journald 之后挂 systemd-journal-remote 或节点上的采集代理即可——采集点在系统层，与容器引擎解耦。

事件流：谁动了容器，systemd 之外的另一双眼睛

podman events 输出镜像、容器、卷、网络的生命周期事件，两个典型用法：

# 用法一：事后审计——过去一天容器层发生了什么
podman events --since 24h --filter type=container
#   ... Pull image docker.io/library/nginx...
#   ... Create container web ...
#   ... Start container web ...
#   ... Die container web ... （含退出码）
# 排查"昨晚谁重启了容器"这类问题，一条命令出时间线

# 用法二：实时订阅——事件驱动的轻量监控
podman events --filter event=died --format '{{.Name}} {{.Attributes.exitCode}}' \
    | while read name code; do
        # 事件处理：告警、记录、联动
        echo "容器 ${name} 以退出码 ${code} 结束" >> ~/container-watch.log
    done
# 无守护进程架构里，"订阅"由这个常驻管道进程完成；
# 把它做成 systemd 服务，就是你的最小容器看护系统
​

事件与日志的组合能回答大部分"容器层发生了什么"的问题：事件给结构化时间线（谁、何时、什么操作），日志给过程细节（进程说了什么）。再加 journald 的服务身份，三个维度交叉定位，绝大多数诡异问题（凌晨自动更新失败、容器被 OOM 杀掉、卷被误删）都能在不装额外平台的情况下查清。

接入系统级监控：思路而非清单

把观测数据送进现有监控栈（Prometheus 生态或任何能抓日志与事件的系统），思路按数据类型分三条：日志类，journald 侧采集（节点代理读 journal，或 systemd-journal-remote 集中化）；事件类，把上面的事件订阅进程的输出转成指标或 webhook；指标类，容器资源指标由 podman stats 按需查询或由系统的 exporter 层提供。核心原则一条：采集点尽量靠系统侧，不靠引擎侧——引擎无守护进程、可被替换，而 systemd 与 journald 是节点的稳定底座。这与 Docker 生态"在 daemon 上挂 exporter"的常规做法形成方法论差异，本质仍是两种哲学在观测层的延伸。

一个完整案例：一次"凌晨容器消失"的完整复盘

背景：某周五凌晨三点，值班收到告警：web 服务不可达。登录机器，podman ps 里容器不在。操作：先查事件流——podman events --since 12h --filter event=died，发现凌晨 02:47 容器 died，退出码 137；再查服务日志——journalctl --user -u web.service，看到 systemd 在 died 后按 Restart 拉起，但 02:48 又死，反复五次后放弃（配置了 StartLimit）；交叉查系统日志——journalctl -k --since 02:40 --until 03:00，内核日志显示 oom-kill 事件，PID 对应容器主进程。结论：凌晨一个批处理任务吃掉了内存，容器被内核 OOM 杀死，重启后再次被杀。处置：给 Quadlet 单元加 systemd 资源配额（MemoryMax），批处理挪到独立容器并限制内存。复盘要点：整个排查没装任何新工具，事件流、服务日志、内核日志三方交叉完成定位——这就是"用 Linux 的方式看容器"的实际收益。变式：若是自动更新引发的镜像问题，时间线会在事件流的 Pull 与 Create 记录里直接显现，配合第 7.2 节的回退流程处理。

本节要点回顾

• 日志直写 journald：podman logs 按容器查、journalctl 按服务查，脚本告警用后者
• 事件流是结构化时间线：事后审计与实时订阅两种用法
• 最小看护系统 = 事件订阅管道 加 systemd 服务：不需要额外平台
• 采集点靠系统不靠引擎：journald 与 systemd 是节点稳定底座
• 三维交叉定位：事件（何时）+ 日志（细节）+ 内核日志（底层原因）