☰

当注销 journald 时，何时会使用库，何时会使用 systemd 配置选项将 StdOut/StdErr 传送到 journald

tag-icon • tag-icon logging systemd journald
当注销 journald 时，何时会使用库，何时会使用 systemd 配置选项将 StdOut/StdErr 传送到 journald

我发现允许注销到 journald 的库，这表明，是的，您应该尽可能使用库并从应用程序内部登录到 journald。

但是还有一些工具，例如systemd-cat或 systemd 配置选项（来自这）：

[Service]
StandardError=journal
StandardOutput=journal
StandardInput=null

这意味着我可以将服务的 stdout/stderr 的输出通过管道传输到 journald，而不必担心执行特定于 journald 的操作，所以现在我不确定。

有人能明确说明何时适合使用一种方法而不是另一种方法吗？（以及任何其他我不知道的方法）

答案1

StandardOutput=journal已是所有服务的默认设置。即使您未明确指定此选项，服务生成的所有输出也会默认自动进入日志。

（这意味着您永远不需要从服务中使用 systemd-cat；它仅在非服务情况下有用，例如 cronjobs 或手动脚本。）

但是使用本机 journald 库（甚至本机 syslog 调用）有两个优点：

  1. 您可以指定消息优先级。非常journalctl -p warning如果管理员可以轻松地按级别过滤消息（例如“警告或更高级别”），而不必滚动浏览数百条无聊的“信息”甚至“调试”级别的消息，这将对管理员很有帮助。

    现在，即使使用 stdout 日志记录，如果启用SyslogLevelPrefix=并确保在每个 stdout 行前面加上前缀<lvl>，这实际上也是可能的，但是没人理会因为这是可选的。

    相反，如果您使用 sd_journal_print() 或甚至传统的 syslog(3) 日志记录功能，那么消息优先级是每次调用的必需参数，因此您别无选择，只能指定它。

    这意味着提供本机 syslog 或 journald 输出的服务通常会为系统管理员提供比将该服务配置为使用 stdout 日志记录更好的体验，而且几乎不会给开发人员带来额外成本。

  2. 您可以将各种自定义元数据附加到每条消息。这特定于本机 journald 日志记录（stdout 和传统 syslog 都不支持它）。其他元数据字段可用于搜索和过滤日志，或由其他工具和脚本提取和使用，而无需它们解析文本消息。

    例如，strongSwan 将 IKE_SA_NAME= 附加到每条消息，因此我可以轻松使用 过滤与我的 VPN 相关的消息journalctl -u strongswan IKE_SA_NAME=home。

    类似地，另一个工具将不同的 MESSAGE_ID= 附加到每种不同类型的消息，因此我可以使用 找到该特定消息的所有实例（即使其措辞发生变化）journalctl -o json MESSAGE_ID=asdf | jq ...。

    使用journalctl -o verbose和journalctl --fields来更好地了解记录的内容（例如，查看 systemd coredump 消息 - coredumpctl 只是日志的一个薄包装）。

因此，如果可用的话，通常优先使用本机 syslog 或 journald 输出，尽管基于 stdout 的日志记录对于简单的工具和脚本（尤其是 shell 脚本）通常“足够好”。

相关内容