我有一个服务，将json的结构化行记录到stdout。使用Upstart，我可以将console.log添加到配置文件中，Upstart将管理将stdout保存到/var/log/upstart/<service-name>.log。另一个服务filebeat将监视此日志文件，将行解析为json，然后将它们转发到要编制索引的elasticsearch。这些日志由logrotate管理，每晚备份到s3。
据我所知，systemd中没有console log等价物。那么问题是将我的日志发送到elasticsearch的最佳方式是什么？
以下是我提出的选项：
这就是我现在正在做的事情，但感觉非常难看。也许我太教条了，但这不符合"12-factor"（我不希望应用程序担心它的stdout是如何被摄取的），而且我已经处理有关文件权限的令人讨厌的调试问题。
还有另一个非正式的＆＃34;击败＆＃34;名为journalbeat，可以从systemd日志中提取日志。这里的主要问题是我不认为它支持像filebeat那样处理json日志行。我可以从filebeat中删除那些东西并将pr发送给journalbeat。
这里的想法是使用shell或其他stdout管理程序启动进程，并使用它来控制日志的保存方式。我认为这几乎不是首发，因为我使用[Service]Type=notify和sdnotify进行启动通知（而且不会消失）。
Logstash可以从journald中获取并具有解析json并转发到es的所有功能。配置会更复杂，我必须运行logstash，这比filebeat重，但无论如何。现在就倾向于这一点。
我对systemd知之甚少，不知道这里有什么可能。我看到StandardOutput可以设置为套接字单元文件提供的文件描述符，但我不确定所有这些是如何组合在一起的，或者它是否可能/务实。
对不起这个问题太久了。任何想法都有帮助！
答案 0 :(得分：1)
继续登录STDOUT是一个好主意。 systemd的原则之一也是由systemd推荐的，并得到容器解决方案的良好支持。
在应用程序中构建日志管理是一个坏主意。该应用程序应该做一件事，并做得很好。当连接暂时关闭时，日志管理会遇到棘手的日志轮换问题或如何处理远程日志传送。
Journalbeat似乎是一个好主意。您是否测试过无法使用JSON日志？ syslog日志的内部日志结构非常类似JSON。
如果Journalbeat无法正常工作，请使用rsyslog守护程序rsyslog来处理任务。无论如何，systemd日志通常默认转发到syslog。 {{1}}有一个Twelve Factor App模块。