systemd journal namespace 怎么隔离服务日志

给一台主机上的多组服务排障时，我更愿意先把“日志筛选”和“日志隔离”分开看。journalctl -u service只是从同一个默认 journal 中过滤，而 systemd 的 LogNamespace= 会让服务进入独立的日志数据流。配置完成后，服务的 stdout、stderr、syslog 和 journal 原生消息都会交给对应的 systemd-journald@.service 实例处理。

官方地址：https://www.freedesktop.org/software/systemd/man/latest/systemd-journald.service.html

先分清过滤日志和隔离日志

按 unit 查询只能改变“看哪些记录”，不会改变日志由哪个 journald 实例接收，也不会改变默认 journal 的容量和轮转边界。namespace 则同时隔离 IPC 入口和数据存储：默认空间由 systemd-journald.service 管理，自定义空间由匹配的 systemd-journald@.service 实例管理。

这适合把高噪声的构建服务、租户工作负载或一组独立业务服务从主机公共日志中分出来。它不等于安全沙箱，也不替代 unit 权限、文件系统权限和容器隔离。

用 LogNamespace=绑定服务的日志入口

不要直接改发行版提供的 unit 文件，给目标服务创建 drop-in。下面的示例把 demo-worker.service 放入名为 demo-worker 的 namespace：

# /etc/systemd/system/demo-worker.service.d/log-namespace.conf
[Service]
# 使用短标识绑定独立 journal 数据流，不填写 /var/log 下的路径。
LogNamespace=demo-worker

# 重新读取 unit 配置，再重启目标服务使绑定生效。
systemctl daemon-reload
systemctl restart demo-worker.service

# 检查 unit 是否带上了目标设置；这里的命令是读者复现用的示例。
systemctl cat demo-worker.service

设置 LogNamespace= 后，systemd 会为这个 namespace 建立所需的 journald socket 依赖。服务本身不需要手工拼接 systemd-journald@demo-worker.service 的启动顺序。namespace 名称宜保持简短、稳定，避免把环境名、日期和实例数量不断编码进去。

用 journalctl 选择单独或联合视图

绑定之后，查询命令的关键是 --namespace=。不带这个选项时，看到的是默认 namespace；带上自定义标识后才读取隔离流。排障时可以把默认流和某个隔离流拼到一起：

# 只查看 demo-worker namespace 中的目标服务最近日志。
journalctl --namespace=demo-worker -u demo-worker.service -n 50 --no-pager

# 同时查看默认 namespace 与 demo-worker，便于对照 systemd 自身消息。
journalctl --namespace=+demo-worker -u demo-worker.service --no-pager

# 交叉查看所有可见 namespace；输出会按时间交错显示。
journalctl --namespace='*' -u demo-worker.service --no-pager

这里的 + 不是 shell 运算符，而是 journalctl 对 namespace 参数的组合语义；命令行中应保持它紧贴 namespace 名称。若只想判断某条记录属于哪个空间，也可以在详细输出中关注 _NAMESPACE 字段。默认空间的记录通常没有这个非默认标识。

用 journald@NAMESPACE.conf 控制存储边界

如果隔离流需要不同的持久化或容量策略，可以为 namespace 写专属配置。文件名中的 NAMESPACE 要替换成实际标识，例如：

# /etc/systemd/journald@demo-worker.conf
[Journal]
# 让该 namespace 优先使用持久化日志；容量值需按磁盘预算调整。
Storage=persistent
SystemMaxUse=2G
SystemKeepFree=1G

这份文件只作用于 demo-worker 的 journald 实例，不会覆盖默认 namespace 的 /etc/systemd/journald.conf。修改 journald 配置后，需要按发行版的管理方式重启或发送信号让 journald 重新读取；生产环境先确认当前 systemd 版本和发行版单元模板的行为，再安排维护窗口。

还要注意一个容易误判的边界：journal namespace 内部使用 Linux mount namespace，并在服务进程的挂载空间中重定向日志 socket。若服务必须在宿主机建立 mount point，隔离日志可能切断它需要的挂载传播；这时应改用按 unit 过滤、独立文件日志或容器级日志设计。

常见问题

只给服务写 LogNamespace=，还需要手工启动 journald 实例吗？

通常不需要。systemd 会为该设置补上匹配的 socket 和服务依赖；手工启动前应先确认 unit 状态，避免把调试动作变成重复管理。

journal namespace 能代替容器隔离吗？

不能。它主要隔离日志 IPC 和数据流，不提供完整的进程、网络、文件系统或权限边界。

为什么服务配置后仍在默认 journal 中出现记录？

先确认查询命令没有遗漏 --namespace=，再检查 drop-in 是否被 systemd 读取。还要区分服务进程日志和 systemd 管理器针对该 unit 产生的关联消息，它们不一定属于同一收集路径。

实际落地时，可以先给一组高噪声服务设置一个稳定 namespace，再用单独查询确认可见范围，最后才决定是否配置独立容量上限。这样既能减少公共日志的干扰，也不会误把日志隔离当成完整的运行时安全边界。