我想将日志从 Java 应用程序发送到 ElasticSearch，而传统的方法似乎是在运行应用程序的服务器上设置 Logstash，并让 Logstash 解析日志文件（使用正则表达式......！）并将它们加载到 ElasticSearch .
这样做是否有原因，而不仅仅是设置 log4J（或 logback）以将所需格式的内容直接记录到日志收集器中，然后可以异步发送到 ElasticSearch？当应用程序本身可以首先将其记录为所需的格式时，我不得不摆弄 grok 过滤器来处理多行堆栈跟踪（并在日志解析时消耗 CPU 周期），这对我来说似乎很疯狂？
在切线相关的说明中，对于在 Docker 容器中运行的应用程序，鉴于只需要运行一个进程，最佳实践是直接登录到 ElasticSearch 吗？
如果您真的想走这条路，那么想法是使用类似Elasticsearch appender（或这个或另一个）之类的东西，它将您的日志直接发送到您的 ES 集群。
但是，出于@Vineeth Mohan 提到的相同原因，我建议不要这样做。您还需要问自己几个问题，但主要是如果您的 ES 集群因任何原因（OOM、网络故障、ES 升级等）宕机会发生什么？
异步存在的原因有很多，其中之一是架构的健壮性，而且大多数时候这比在日志解析上消耗更多的 CPU 周期更重要。
另请注意，官方 ES 讨论论坛上正在进行关于这个主题的讨论。
我认为从 Log4j/Logback/whatever appender 直接登录到 Elasticsearch 通常是不明智的，但我同意编写 Logstash 过滤器来解析“正常”人类可读的 Java 日志也是一个坏主意。我在任何地方都可以使用https://github.com/logstash/log4j-jsonevent-layout让 Log4j 的常规文件附加程序生成 JSON 日志，这些日志不需要 Logstash 进一步解析。
还有https://github.com/elastic/java-ecs-logging，它提供了 log4j、log4j2 和 Logback 的布局。它非常高效，而且 Filebeat 配置非常少。
免责声明：我是这个库的作者。
如果你需要一个快速的解决方案，如果你想使用它，我已经在Log4J2 Elastic REST Appender写了这个附加程序。它能够在将日志事件发送到 Elastic 之前根据时间和/或事件数量缓冲日志事件（使用 _bulk API 以便一次性发送所有事件）。它已发布到 Maven Central，因此非常简单。
正如其他人已经提到的那样，最好的方法是将其保存到文件中，然后将其单独发送到 ES。但是，我认为如果您需要快速运行某些东西，直到您有时间/资源实施最佳方式，这是有价值的。