![当注销 journald 时,何时会使用库,何时会使用 systemd 配置选项将 StdOut/StdErr 传送到 journald](https://linux22.com/image/785837/%E5%BD%93%E6%B3%A8%E9%94%80%20journald%20%E6%97%B6%EF%BC%8C%E4%BD%95%E6%97%B6%E4%BC%9A%E4%BD%BF%E7%94%A8%E5%BA%93%EF%BC%8C%E4%BD%95%E6%97%B6%E4%BC%9A%E4%BD%BF%E7%94%A8%20systemd%20%E9%85%8D%E7%BD%AE%E9%80%89%E9%A1%B9%E5%B0%86%20StdOut%2FStdErr%20%E4%BC%A0%E9%80%81%E5%88%B0%20journald.png)
我发现允许注销到 journald 的库,这表明,是的,您应该尽可能使用库并从应用程序内部登录到 journald。
但是还有一些工具,例如systemd-cat
或 systemd 配置选项(来自这):
[Service]
StandardError=journal
StandardOutput=journal
StandardInput=null
这意味着我可以将服务的 stdout/stderr 的输出通过管道传输到 journald,而不必担心执行特定于 journald 的操作,所以现在我不确定。
有人能明确说明何时适合使用一种方法而不是另一种方法吗?(以及任何其他我不知道的方法)
答案1
StandardOutput=journal
已是所有服务的默认设置。即使您未明确指定此选项,服务生成的所有输出也会默认自动进入日志。
(这意味着您永远不需要从服务中使用 systemd-cat;它仅在非服务情况下有用,例如 cronjobs 或手动脚本。)
但是使用本机 journald 库(甚至本机 syslog 调用)有两个优点:
您可以指定消息优先级。非常
journalctl -p warning
如果管理员可以轻松地按级别过滤消息(例如“警告或更高级别”),而不必滚动浏览数百条无聊的“信息”甚至“调试”级别的消息,这将对管理员很有帮助。现在,即使使用 stdout 日志记录,如果启用
SyslogLevelPrefix=
并确保在每个 stdout 行前面加上前缀<lvl>
,这实际上也是可能的,但是没人理会因为这是可选的。相反,如果您使用 sd_journal_print() 或甚至传统的 syslog(3) 日志记录功能,那么消息优先级是每次调用的必需参数,因此您别无选择,只能指定它。
这意味着提供本机 syslog 或 journald 输出的服务通常会为系统管理员提供比将该服务配置为使用 stdout 日志记录更好的体验,而且几乎不会给开发人员带来额外成本。
您可以将各种自定义元数据附加到每条消息。这特定于本机 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 脚本)通常“足够好”。