如何从 systemd 管理的应用程序中提取日志

How to ingest logs from app managed by systemd

我有一项服务可以将 json 的结构化行记录到标准输出。使用 Upstart,我可以将 console.log 添加到配置文件,然后 Upstart 将管理将标准输出保存到 /var/log/upstart/<service-name>.log。另一个服务 filebeat 会监视这个日志文件,将行解析为 json,然后将它们转发到 elasticsearch 进行索引。这些日志由 logrotate 管理并每晚备份到 s3。

据我所知,systemd 中没有 console log 等价物。那么问题是将我的日志发送到 elasticsearch 的最佳方式是什么?

以下是我想出的选项:

将日志文件管理构建到应用程序中

这就是我现在正在做的,但感觉很丑陋。也许我太教条了,但这不符合 "12-factor" 标准(我不想让应用程序担心它的 stdout 是如何被摄取的),而且我已经处理了关于文件权限。

journalbeat

还有另一个名为 journalbeat 的非官方 "beat" 可以从 systemd 日志中获取日志。这里的主要问题是我认为它不像 filebeat 那样支持处理 json 日志行。我可以从 filebeat 中删除这些东西并将 pr 发送到 journalbeat。

Shell 重定向,或类似的

这里的想法是使用 shell 或其他一些标准输出管理程序启动进程,并使用它来控制日志的保存方式。我认为这几乎是一个非启动器,因为我使用 [Service]Type=notify 和 sdnotify 作为启动通知(并且不会消失)。

使用 logstash

Logstash 可以从 journald 中摄取并具有解析 json 并转发到 es 的所有功能。配置会更复杂,我将不得不 运行 logstash,它比 filebeat 更重,但无论如何。现在倾向于这个。

系统魔法

我对 systemd 的了解还不够,不知道这里有什么可能。我看到 StandardOutput 可以设置为套接字单元文件提供的文件描述符,但我不确定所有这些是如何组合在一起的,或者它是否甚至 possible/pragmatic.

抱歉这个问题太长了。任何想法都有帮助!

继续登录到 STDOUT 是个好主意。它是 Twelve Factor App 的原则之一,也被 systemd 推荐,并得到容器解决方案的良好支持。

在应用程序中构建日志管理不是一个好主意。该应用程序应该做一件事并且把它做好。日志管理陷入日志轮换或连接暂时中断时如何处理远程日志传送的棘手问题。

Journalbeat 似乎是个好主意。您是否测试过 不能 使用 JSON 日志? systemd 日志的内部日志结构很像 JSON。

如果 Journalbeat 不起作用,请使用 syslog 守护进程,如 rsyslog 来处理任务。无论如何,systemd 日志通常默认转发到 syslog。 rsyslog 有一个模块用于 forwarding logs to Elasticsearch