无需解析日志即可从 Java 应用程序记录到 ELK答案

【问题标题】：Logging from Java app to ELK without need for parsing logs无需解析日志即可从 Java 应用程序记录到 ELK
【发布时间】：2015-11-24 23:12:35
【问题描述】：

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

这样做是否有原因，而不是仅仅设置 log4J（或 logback）以将所需格式的内容直接记录到日志收集器中，然后可以异步发送到 ElasticSearch？当应用程序本身可以首先将其记录为所需的格式时，我不得不摆弄 grok 过滤器来处理多行堆栈跟踪（并在日志解析时消耗 CPU 周期），这对我来说似乎很疯狂？

另一方面，对于在 Docker 容器中运行的应用程序，最好的做法是直接登录到 ElasticSearch，因为只需要运行一个进程？

【问题讨论】：

即使你将一个漂亮的 json 文档直接发送到 elasticsearch，仍然可以在途中应用商业智能。这对logstash 很有用。此外，大多数人并不生活在一个异构的世界中，因此使用一个聚合器可能会很强大。 tmtowtdi，当然。
我觉得这主要是因为可扩展性的原因。如果应用程序正在向 Elasticsearch 推送日志，那么来自 ELlasticsearch 的慢速背压会影响应用程序的性能，如果应用程序在主内存中排队大量日志，则肯定会产生不利影响。

标签： java logging elasticsearch logstash elastic-stack

【解决方案1】：

如果您真的想沿着这条路走下去，建议使用Elasticsearch appender（或this one 或this other one）之类的东西，它将您的日志直接发送到您的ES 集群。

但是，出于@Vineeth Mohan 提到的相同原因，我建议不要这样做。您还需要问自己几个问题，但主要是如果您的 ES 集群由于任何原因（OOM、网络故障、ES 升级等）宕机会发生什么？

存在异步性的原因有很多，其中之一是架构的稳健性，而且大多数情况下这比在日志解析上消耗更多 CPU 周期更重要。

另请注意，官方 ES 讨论论坛中有一个关于这个主题的 ongoing discussion。

【讨论】：

从结构化数据中发出不明确的文本日志并再次解析它是不必要的复杂化。这与 CPU 周期无关，而与数据的稳健性有关。当它们最初是结构化的时仔细提取堆栈跟踪是一种耻辱......而且我不明白你为什么对 ES 集群争论不休（特别是如果你通过复制配置冗余）。很可能会看到 Logstash/Flume 甚至 Kafka/Redis 比 ES 死...
@gavenkoa 我不知道你的情况，你的里程可能会有所不同。当然，在单个开发或暂存节点上，这是没有意义的，但经验表明，由于多种原因，拥有这种异步管道在实际生产设置中提供了更多的健壮性。随意用您的详细用例创建一个问题，我们可以讨论它。

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

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

【讨论】：

【解决方案4】：

如果你需要一个快速的解决方案，如果你想使用它，我已经在Log4J2 Elastic REST Appender 写了这个附加程序。它能够在将日志事件发送到 Elastic 之前根据时间和/或事件数量缓冲日志事件（使用 _bulk API 以便一次性发送所有事件）。它已发布到 Maven Central，因此非常简单。

正如其他人已经提到的那样，最好的方法是将其保存到文件中，然后单独发送到 ES。但是，我认为如果您需要快速运行某些东西，直到您有时间/资源以最佳方式实施，这是有价值的。

【讨论】：