小编mar*_*ton的帖子

您如何分析来自 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 有日志插件，但我对比每个主机警报更具可扩展性和层次性的东西感兴趣。

GNU find（和其他人？）有一个-true测试以及正常的-name，-mode，-user等等。从手册页：

-true 始终为真。

每次我看到手册页时，我都会注意到这一点，并想知道它什么时候有用。所以，给我一些什么时候有用的例子:~)

我们经常让服务器中的 DIMM 变坏，系统日志中出现以下错误：

5 月 7 日 09:15:31 nolcgi303 内核：EDAC k8 MC0：一般总线错误：参与处理器（本地节点响应）、超时（无超时）内存事务类型（通用读取）、内存或 I/O（内存访问） , 缓存级别（通用）
5 月 7 日 09:15:31 nolcgi303 内核：MC0：CE 页 0xa0，偏移量 0x40，grain 8，综合症 0xb50d，第 2 行，通道 0，标签“”：k8_edac
5 月 7 日 09:15:31 nolcgi303 内核：MC0：CE - 无可用信息：k8_edac 错误溢出集
5 月 7 日 09:15:31 nolcgi303 内核：EDAC k8 MC0：扩展错误代码：ECC chipkill x4 错误

我们可以使用 HP SmartStart CD 来确定哪个 DIMM 有错误，但这需要使服务器停止生产。是否有一种巧妙的方法可以在服务器启动时确定哪个 DIMM 失效？我们所有的服务器都是运行 RHEL 5 的 HP 硬件。

应该/etc/localtime（在 RHEL 5.3 下，我认为这并不重要）是：

1. 一个符号链接 /usr/share/zoneinfo/whatever
2. 硬链接 /usr/share/zoneinfo/whatever
3. 一份 /usr/share/zoneinfo/whatever

我更喜欢 1)，因为它通过 Puppet 管理起来很明确而且很容易，但它会破坏任何东西吗？RedHat 的默认看起来是 3)。编辑：我知道跨文件系统符号链接、tzdata 更新等的常见问题，但不知道历史上的 no-/usr-during-rc.sysinit 问题。谢谢大家！

我们每天轮换和压缩我们的 Apache 日志，但很明显这不够频繁。一个未压缩的日志大约是 6G，这已经接近填满我们的日志分区（是的，我们将来会把它做得更大！）并且每天都需要花费大量的时间和 CPU 来压缩。我们必须为我们的统计处理每天生成一个 gziped 日志。显然，我们可以将日志移动到具有更多空间的分区，但我也希望全天分散压缩开销。

使用 Apache 的rotatelogs，我们可以更频繁地轮换和压缩日志——比如说，每小时——但是我怎样才能将所有每小时压缩的日志连接成当天正在运行的压缩日志，而无需解压以前的日志？我不想解压缩 24 小时的数据并重新压缩它，因为这具有我们当前解决方案的所有缺点。

Gzip 似乎没有提供任何附加或连接选项，但也许我错过了一些明显的东西。这个问题表明直接 shell 连接“有效”，因为可以解压缩存档，但这gzip -l似乎不起作用。

或者，也许这仍然是一种糟糕的做事方式。欢迎其他建议——我们唯一的限制是我们相对较小的日志分区和提供每日压缩日志的需要。