在不需要解析日志的情况下，将Java应用程序的日志记录到ELK中。

Question

我想把Java应用程序的日志发送到ElasticSearch，传统的方法似乎是在运行应用程序的服务器上设置Logstash，并让logstash解析日志文件（用正则表达式...！）并将它们加载到ElasticSearch中。

难道不直接设置log4J（或logback）以所需格式直接记录日志并将其发送到异步日志收集器，再将其分发到ElasticSearch中更好吗？对于我来说，似乎没必要通过grok过滤处理多行堆栈跟踪（并在日志解析时消耗CPU周期），而应用程序本身可以一开始就以所需格式记录它。

在与此有关的另一个问题上，对于运行在Docker容器中的应用程序，最佳实践是直接记录到ElasticSearch中，考虑到只需要运行一个进程吗？

- Rob

---

即使您将一个漂亮的JSON文档直接发送到Elasticsearch，仍然可能需要应用业务智能。这是使用Logstash的绝佳用途。此外，大多数人不生活在异构世界中，因此使用一个聚合器可以非常强大。当然，有许多方法可以做到这一点。 - Alain Collins

我认为这主要是因为可扩展性的原因。如果应用程序正在将日志推送到Elasticsearch，由于Elasticsearch的缓慢而导致的背压可能会影响应用程序的性能，如果应用程序在主内存中排队了大量的日志，那么它肯定会产生不利影响。 - Vineeth Mohan

Answer 1

如果您真的想走这条路，那么想法就是使用像Elasticsearch appender（或这个或另一个）这样的东西，可以直接将日志发送到ES集群。但出于@Vineeth Mohan提到的相同原因，我建议不要这样做。您还需要问自己一些问题，但主要是如果您的ES集群因任何原因（OOM、网络故障、ES升级等）崩溃会发生什么？存在许多异步性的原因之一是您的架构的鲁棒性，而大多数时候，这比在日志解析上烧掉更多的CPU周期要重要得多。此外，请注意，在官方ES讨论论坛中正在进行关于这个非常主题的持续讨论。

- Val

---

从结构化数据中发出模糊的文本日志并再次解析它是不必要的复杂化。这不是关于CPU周期，而是关于数据的稳健性。当堆栈跟踪最初被结构化时，仔细提取它们是一件遗憾的事情...我不明白为什么你会担心ES集群（特别是如果你通过复制配置冗余）。看到Logstash/Flume甚至Kafka/Redis死亡的可能性比看到ES死亡的可能性更大... - gavenkoa

@gavenkoa 我不知道你的上下文，你的情况可能有所不同。当然，在单个开发或暂存节点上，这是没有意义的，但经验表明，在真实的生产环境中，由于多种原因，拥有这种异步流水线可以提供更多的稳健性。欢迎创建一个包含详细用例的问题，我们可以讨论一下。 - Val

Answer 2

还有一个https://github.com/elastic/java-ecs-logging，它为log4j、log4j2和Logback提供了布局。它非常高效，Filebeat配置也非常简单。

免责声明：我是这个库的作者。

- Felix

Answer 3

我认为直接从Log4j / Logback /任何appender记录到Elasticsearch通常不明智，但我同意编写Logstash过滤器来解析“正常”的可读Java日志也是一个坏主意。我尽可能地使用https://github.com/logstash/log4j-jsonevent-layout，让Log4j的常规文件appender生成JSON日志，无需通过Logstash进行进一步解析。

- Magnus Bäck

Answer 4

如果您需要快速解决问题，我已经编写了这个应用程序附加器Log4J2 Elastic REST Appender，如果您想要使用它的话。它具有根据时间和/或事件数量缓冲日志事件并将其发送到Elastic的能力（使用_bulk API以便一次性发送所有内容）。它已发布到Maven Central，因此非常简单。

正如其他人已经提到的，最好的方法是将其保存到文件中，然后单独将其发送到ES。但是，我认为在您有时间/资源实现最佳方式之前，如果需要快速启动某些东西，这将非常有价值。

- Marcelo Grossi