Java 管理分布在多台计算机上的大量日志文件

我们已经开始使用第三方平台（GigaSpaces）来帮助我们进行分布式计算。我们现在试图解决的主要问题之一是如何在这种分布式环境中管理日志文件。我们目前有以下设置

我们的平台分布在8台机器上。在每台机器上，我们有12-15个进程，它们使用java.util.logging记录到单独的日志文件。在这个平台之上，我们有自己的应用程序，它们使用log4j和log来分离文件。我们还将stdout重定向到一个单独的文件，以捕获线程转储和类似事件

这将导致大约200个不同的日志文件

到目前为止，我们还没有工具来帮助管理这些文件。在以下情况下，这会导致我们严重头痛

• 当我们事先不知道问题发生在哪个过程时进行故障排除。在本例中，我们当前使用ssh登录到每台机器，并开始使用

  grep

• 通过定期检查日志中的任何异常情况，努力做到主动。在本例中，我们当前还登录到所有计算机，并使用

  less

  和

  tail

  查看不同的日志

• 设置警报。我们希望在超过阈值的事件上设置警报。要检查200个日志文件，这看起来很麻烦

今天，我们每秒只有大约5个日志事件，但随着我们将越来越多的代码迁移到新的平台，这将增加

我想向社区提出以下问题

• 您如何处理通过不同框架记录的多台机器上分布的许多日志文件的类似情况
• 你为什么选择那个特殊的解决方案
• 你的解决方案是如何运作的？你觉得什么好，什么不好

非常感谢

更新

---

我们最终评估了Splunk的试用版。我们对它的工作方式非常满意，并决定购买它。易于设置，快速搜索，并为有技术倾向的用户提供大量功能。我可以推荐任何处于类似情况的人来查看它。

我建议看一看像或这样的日志聚合工具

---

（另外，我认为这更像是一个服务器故障问题，因为它与应用程序及其数据的管理有关，与创建应用程序无关。）

我能给你的唯一建议是确保通过代码传递事务ID，并确保在登录时记录它，因此，您以后可以将不同的调用关联在一起。

我建议将所有java日志通过管道传输到（SLF4J），然后将所有日志从SLF4J重定向到。SLF4J特别支持处理所有流行的遗留API（log4j、commons日志、java.util.logging等），请参阅

在LogBack中设置日志后，您可以使用其中的一个appender来聚合多台机器上的日志，有关详细信息，请参阅手册。套接字、JMS和SMTP似乎是最明显的候选

LogBack还内置了监控日志文件中特殊情况的支持，并过滤发送到特定appender的事件。因此，您可以设置SMTP appender，以便在每次日志中出现错误级别事件时向您发送电子邮件

最后，为了简化故障排除，请确保在所有传入的“请求”中添加某种类型的requestID，有关详细信息，请参阅我对的回答

---

编辑：您还可以实现自己的自定义LogBack appender，并将所有日志重定向到。

一个有趣的探索选项是在这些节点上运行，并编写一个自定义作业，用于搜索和聚合特定于您的应用程序的结果。

我会将文件传输到一台集中的计算机在其上运行分析器机制。可能你可以使用Hadoop集群来完成这项工作，并运行map/reduce作业来进行分析……每隔5分钟将其复制到Hadop集群等。我不确定这是否符合你的需要。在这种关系中，不妨看看前面提到的Scribe。

谢谢您的建议。你对这些工具有什么经验？在ServerFault上可能确实更好，我同意。我已经使用splunk查看了大约40台服务器的日志。真的很不错。唯一的缺点是前端有点沉重（javascript magic使ubuntu上的firefox崩溃），但很可能从那以后它有所改进。就我个人而言，我还没有处理过让Splunk自动拾取日志数据的问题，只是手动将数据导入其中——但它的前端和分析工具看起来非常棒，值得指出，将所有内容重定向到Scribe实际上会在系统中造成单点故障，例如，当Scribe守护进程关闭时。好的，最终解决方案的容错方面通常非常特定于部署，因此，留给负责最终解决方案的架构师作为练习。尽管如此，还是要记住这一点。我想补充一点，这并不是真正的“单点故障”，因为如果Scribe central node关闭，整个解决方案不会受到影响-单个Scribe node只是在本地排队等待日志记录，直到central node再次备份。Scribe停机时间仅影响日志记录子系统的可用性。