Linux systemd 怎样把服务日志分离到独立标识

可以在 systemd 服务的 [Service] 配置中设置 SyslogIdentifier=invoice-worker，并将标准输出和标准错误接入 journal，再用 journalctl -t invoice-worker 筛选。这里的“分离”是检索视图上的分类，不会自动生成独立日志文件，也不是访问权限隔离。

官方说明：https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html。以下使用虚构的 invoice-worker.service 演示配置，命令供读者按环境执行，本文未修改实际系统服务。

我会先把检索目标限定为标准输出

面对多个进程都由同一种解释器启动的场景，我会先判断自己想查的是应用输出，还是服务启动、退出等管理事件。前者适合约定一个易记标识，后者仍要保留按单元查看的入口。

SyslogIdentifier 作用于由服务 stdout/stderr 写出的相应日志流，不意味着应用通过 syslog 或 journal 原生接口提交的字段也被统一覆盖。对我来说，这个边界比名字是否好看更重要：先把数据来源说清，再约定查询命令。

示例把服务单元、标准输出、标准错误、日志标识和 journal 看成不同对象。标识是日志记录的检索属性，不是新的存储服务。

给现有服务配置固定标识

在已有服务的专用 drop-in 文件中加入以下内容，例如由配置管理维护 /etc/systemd/system/invoice-worker.service.d/40-log-identifier.conf。这不是完整服务定义，不包含 ExecStart；不要直接覆盖发行版提供的主单元文件。

# 仅覆盖这个服务的日志相关设置
[Service]
# 显式把两条标准流接入 journal，应用必须确实写入这些流
StandardOutput=journal
StandardError=journal
# 使用稳定的业务名称，不填写用户隐私或动态请求数据
SyslogIdentifier=invoice-worker

如果原服务把输出写入文件，这项改动会改变标准流去向，应先确认现有日志采集方式。应用若本来就只写自有日志文件，单改这里不会把文件内容主动搬进 journal。

# 查看当前单元和 drop-in，先确认自己修改的是目标服务
systemctl cat invoice-worker.service
# 让管理器重读单元定义；这一步不等于重启应用
sudo systemctl daemon-reload
# 在允许短暂中断的维护窗口重启，使新进程采用日志配置
sudo systemctl restart invoice-worker.service

我会把重启动作与业务发布窗口绑定，而不是为了改一个标签随时打断任务。用户级服务需要对应的 --user 管理器与配置位置，不能直接混用系统级命令。

把标识查询与单元查询分开使用

# 看当前启动周期内、最近十分钟的指定标识，避免翻到旧记录
journalctl -b -t invoice-worker --since "10 minutes ago" --no-pager
# 看服务单元相关日志，包含管理器针对该单元的事件
journalctl -b -u invoice-worker.service --since "10 minutes ago" --no-pager
# 查看结构化字段，确认实际记录的标识和值
journalctl -b -t invoice-worker -n 5 -o verbose --no-pager

-t 对应 SYSLOG_IDENTIFIER，而 -u 表达单元维度。它们不是两种完全等价的拼写：服务管理事件可能由管理器产生，不必带着应用的标识。因此只看 -t 的输出，可能错过启动失败等线索。

我通常把前两条分别保留在交接记录里：一条用于阅读业务输出，另一条用于查看单元生命周期。第三条用于让读者确认真实字段，不是要求截图，也没有预设一定会出现哪条消息。

没有查到日志时先看这几个边界

第一种情况是时间范围不对。新标识不会追溯改写历史记录，所以先确认新配置对应的新进程已经启动，并且在查询窗口内有输出。第二种情况是日志根本没走标准流，此时应回到应用日志配置，而不是反复换标识名称。

第三种情况是多个服务使用同一个标识。按 -t 查询会聚合相同字段值，因此命名约定应先明确是按业务聚合，还是让每个服务单元保持不同名称。不能把一个易读标识当成身份认证依据。

第四种情况是查看权限或 journal 范围不同。先使用环境已授权的日志访问方式，不要为了读日志随意扩大文件权限。服务是否运行、应用是否产生输出、读取者是否能看到对应 journal，是不同问题。

回退配置并保留命名约定

若输出去向不符合原采集需求，应由配置管理恢复本次专用 drop-in 的上一版内容，再重读单元定义，并按维护窗口重启。不要为了回退日志标签，把这个服务所有无关覆盖配置一并删除。

我的取舍是：仅需要统一阅读入口时，固定标识足够轻；若真正需要分开保存或隔离，不应把本例当作完整方案。标识名、服务名、输出渠道和部署版本这四项一起记录，比只在文档里留一条查询命令更便于后续维护。

为什么旧日志仍显示原名称？配置不改写旧记录。为什么 -u 能看到而 -t 看不到？先区分管理器事件和应用日志，再核对字段。为什么没有产生独立文件？因为标识只是记录分类，不是文件输出配置。

参考：systemd.exec 日志配置；journalctl 查询选项；systemctl 单元重读与重启。