mar*_*ton 14 linux unix monitoring logging
您如何分析来自 UNIX/Linux 机器的日志文件？我们运行数百台服务器，它们都直接或通过 syslog 生成自己的日志文件。我正在寻找一个不错的解决方案来汇总这些并挑选出重要的事件。这个问题分为 3 个部分：
1) 消息传输
经典的方法是使用 syslog 将消息记录到远程主机。这对于登录到 syslog 的应用程序很有效，但对于写入本地文件的应用程序不太有用。解决方案可能包括让应用程序登录到连接到程序的 FIFO 以使用 syslog 发送消息，或者通过编写一些内容来 grep 本地文件并将输出发送到中央 syslog 主机。然而，如果我们不厌其烦地编写工具来将消息导入系统日志，我们是否会更好地用 Facebook 的Scribe 之类的东西来替换整个系统，它比系统日志提供更多的灵活性和可靠性？
2）消息聚合
日志条目似乎属于两种类型之一：每主机和每服务。Per-host 消息是发生在一台机器上的消息；考虑磁盘故障或可疑登录。Per-service 消息出现在大多数或所有运行服务的主机上。例如，我们想知道 Apache 何时发现 SSI 错误，但我们不希望 100 台机器出现相同的错误。在所有情况下，我们只希望看到每种类型的消息中的一个：我们不希望有 10 条消息说同一个磁盘发生故障，并且我们不希望每次遇到损坏的 SSI 时都收到一条消息。
解决此问题的一种方法是在每个主机上将多个相同类型的消息聚合为一个，将这些消息发送到中央服务器，然后将相同类型的消息聚合为一个整体事件。SER可以做到这一点，但使用起来很尴尬。即使经过几天的摆弄，我也只能进行基本的聚合，并且不得不不断查找 SER 用于关联事件的逻辑。这是强大但棘手的东西：我需要一些我的同事可以在最短的时间内拿起和使用的东西。SER 规则不符合该要求。
3) 生成警报
当有趣的事情发生时，我们如何告诉我们的管理员？邮寄群组收件箱？注入Nagios？
那么，你是如何解决这个问题的？我不指望盘子上有答案；我可以自己解决细节问题，但就什么是常见问题进行一些高层讨论会很棒。目前，我们正在使用 cron 作业、系统日志以及谁知道还有什么可以找到事件的大杂烩。这不是可扩展的、可维护的或灵活的，因此我们错过了很多我们不应该的东西。
更新：我们已经在使用 Nagios 进行监控，这对于检测到的主机/测试服务/等非常有用，但对于抓取日志文件不太有用。我知道 Nagios 有日志插件，但我对比每个主机警报更具可扩展性和层次性的东西感兴趣。