4
大规模日志传输和聚合
已锁定。该问题及其答案被锁定，因为该问题是题外话，但具有历史意义。它目前不接受新的答案或互动。 您如何分析UNIX / Linux计算机上的日志文件？我们运行数百台服务器，这些服务器都直接或通过syslog生成自己的日志文件。我正在寻找一个不错的解决方案来汇总这些信息并挑选重要事件。该问题分为三个部分： 1）消息传输 经典方法是使用syslog将消息记录到远程主机。这对于登录到syslog的应用程序效果很好，但对写入本地文件的应用程序则没什么用。解决方案可能包括使应用程序登录到与程序连接的FIFO中，以使用syslog发送消息，或者编写一些东西将grep本地文件并将输出发送到中央syslog主机。但是，如果麻烦编写工具将消息发送到syslog中，那么我们最好用Facebook的Scribe这样的东西代替syslog来替代全部内容，这样更好吗？ 2）消息聚合 日志条目似乎属于以下两种类型之一：每个主机和每个服务。每主机消息是在一台计算机上发生的消息。考虑磁盘故障或可疑登录。每服务消息出现在大多数或所有运行服务的主机上。例如，我们想知道Apache何时发现SSI错误，但我们不希望100台计算机中出现相同的错误。在所有情况下，我们只希望看到每种类型的消息中的一种：我们不希望10条消息表明同一磁盘已发生故障，并且每次击破SSI时我们都不需要消息。 解决此问题的一种方法是将同一类型的多个消息聚合到每个主机上，然后将消息发送到中央服务器，然后将相同类型的消息聚合到一个整体事件中。SER可以做到这一点，但是使用起来很尴尬。即使经过几天的摆弄，我也只能使用基本的聚合，并且必须不断查找SER用于关联事件的逻辑。它是功能强大但棘手的东西：我需要我的同事可以在最短时间内获取和使用的东西。SER规则不符合该要求。 3）生成警报 当有趣的事情发生时，我们如何告诉管理员？邮寄群组收件箱？注入Nagios吗？ 那么，您如何解决这个问题？我不希望盘子里有答案。我可以自己制定细节，但是就什么是常见问题进行一些高级讨论会很棒。目前，我们正在使用大量的cron作业，syslog和谁知道还能找到事件的人。这是不可扩展的，不可维护的或灵活的，因此我们错过了很多本不应该的东西。 已更新：我们已经在使用Nagios进行监视，这对于检测到关闭的主机/测试服务/等非常有用，但对抓取日志文件的用处较小。我知道有一些用于Nagios的日志插件，但是我对比每主机警报更具可扩展性和层次性的东西感兴趣。