多节点环境中的Java日志记录最佳实践

在我的公司，我在多节点基础设施中管理一个大型应用程序（>10万用户），由3台（但可能更多）应用服务器组成。 每个应用服务器都有5个不同的日志文件，其中记录了有关http/s（REST或SOAP）请求和对其他（外部）子系统的响应的几乎所有信息。我使用ApacheHTTP客户端来处理REST流、wsimport生成的SOAP请求客户端和Logback作为日志记录技术

目前，当我被要求调试某些东西时，我必须做的最复杂和最耗时的任务是确定我必须调试的节点。在那之后，我必须实际grep大量的行以发现发生了什么。老实说，我觉得它很无聊、过时，而且很复杂

为了让我的生活更轻松，让我的日志更有趣，我在过去的几天里查看了elasticsearch堆栈（elasticsearch、logstash、kibana），并播放了他们的docker图像。我发现它们非常有趣，我想在我的应用程序中介绍它们，但在这样做之前，我想知道是否有做类似事情的最佳实践/模式

以下是我的疑问：

• 在记录Http/s REST和SOAP请求/响应（我需要查看所有内容：url、头、路径、正文、cookies等）时，是否有一种可以通过logstash/elasticsearch轻松解析的格式的最佳实践
• 考虑到我的基础设施，我应该为我的logback实现使用elasticsearch appender，还是使用Logstash作为日志处理器（我假设每个应用服务器都有一个）
• 是否有有效的替代方案来满足我的要求，以回登录和elasticsearch技术

我不希望得到一个简单易行的答案。我想了解不同的经历，以便做出最适合我的解决方案的选择

谢谢

是否有最佳实践[…]格式[…]协议]

我不知道任何日志标准已经有了您想要的字段。因此，您需要一种可以存储自定义元数据的格式。您可以使用RFC5424格式向系统日志消息添加元数据。我还看到各种日志服务通过套接字连接接受JSON格式的消息

我应该使用elasticsearch追加器吗

我建议直接发送到logstash，而不是直接发送到ElasticSearch

Logstash设计用于接收和解析各种格式的消息，因此以Logstash理解的格式发送消息比以ElasticSearch理解的格式发送消息更容易

随着日志需求的发展：您将能够 在一个地方（Logstash）进行更改，而不是重新配置每个应用程序实例

• 这包括操作更改，例如更改ElasticSearch群集的地址

Logstash可以执行诸如审查日志之类的操作（删除看起来像密码或地址的内容）

Logstash可以将日志发送到各种下游服务。例如：如果遇到重要错误，它会触发PagerDuty通知或松弛消息

Logstash可以使用附加元数据丰富日志消息（例如，从IP地址解密地理坐标）

也可能存在规模问题。我没有足够的知识来评论这些，但我的直觉是：我希望Logstash能够很好地处理大量连接（并优雅地处理连接故障）。我不知道这在ElasticSearch集群的设计中是否是一个类似的优先级，或者ElasticSearch的搜索性能是否会受到大量代理同时连接到它的影响。我更相信Logstash的设计是考虑到这种用途的

您还可能发现ElasticSearch appender有一些局限性。appender需要对许多事情有良好的支持。首先想到的是：

• 协议、加密的选择
• 压缩的选择
• 完全控制日志消息的格式（包括自定义字段）
• 对发送异常等特殊消息的控制

通过坚持支持良好的标准（如syslog appender），可以避免特定于技术的appender的任何限制

是否有有效的替代方案来满足我的要求，以回登录和elasticsearch技术

你的意思是说logstash（即“是否有麋鹿堆的替代品”？）如果这是你的意图，那么我没有答案

但就logback的替代方案而言，我使用log4j2。它提供异步日志记录，以减少应用程序的性能负担。也许logback也有这个功能。在log4j2日志消息中发送自定义字段很困难（目前对转义JSON的支持较差。插件可用，但您的构建需要正确设置才能支持这些）。对我来说，最简单的方法是使用RFC5424系统日志追加器

---

考虑将Java应用程序设计为调用日志外观（即SLF4J），而不是直接调用logback。这使您能够在将来轻松地切换到其他日志记录提供程序。

以下是其中一个复杂的答案：） ELK stack绝对可以让您在分布式环境中的生活更加轻松。 然而，为了从中获益，可以考虑以下做法：

• 在ElasticSearch的日志消息中，您应该看到以下内容（除了明显的时间、级别和消息本身）：
  • 产生大量消息的服务器
  • 发起请求的用户
  • 如果您的应用程序是多租户-处理请求的租户
• 所有消息应具有相同的结构（层