1)消息传输

经典的方法是使用syslog将消息记录到远程主机.这适用于登录syslog的应用程序,但对写入本地文件的应用程序不太有用.解决方案可能包括让应用程序登录到连接到程序的FIFO以使用syslog发送消息,或者编写将grep本地文件并将输出发送到中央syslog主机的内容.但是,如果我们遇到编写工具以将消息输入syslog的麻烦,我们会更好地用Facebook的Scribe替换整个批次,它提供比syslog更多的灵活性和可靠性吗？

2)消息聚合

日志条目似乎分为两种类型之一：per-host和per-service.每主机消息是在一台机器上发生的消息;认为磁盘故障或可疑登录.每个服务消息发生在运行服务的大多数或所有主机上.例如,我们想知道Apache何时发现SSI错误但我们不希望100台机器出现相同的错误.在所有情况下,我们只希望看到每种类型的消息中的一种：我们不希望10条消息说同一磁盘发生故障,并且每次遇到损坏的SSI时我们都不希望发出消息.

解决此问题的一种方法是在每个主机上将相同类型的多个消息聚合为一个,将消息发送到中央服务器,然后将相同类型的消息聚合到一个整体事件中. SER可以做到这一点,但使用起来很尴尬.即使经过几天的摆弄,我只有基本的聚合工作,不得不经常查找SER用于关联事件的逻辑.它是强大但棘手的东西：我需要一些我的同事可以在最短的时间内拿起并使用的东西. SER规则不符合该要求.

3)生成警报

当有趣的事情发生时,我们如何告诉我们的管理员？邮寄群组收件箱？注入Nagios？

那么,你是如何解决这个问题的呢？我不希望在盘子上找到答案;我自己可以弄清楚细节,但是对于什么是一个常见问题的一些高级别讨论会很棒.目前我们正在使用cron job的cishmash,syslog以及谁知道还有什么可以找到事件.这不是可扩展的,可维护的或灵活的,因此我们错过了很多我们不应该做的事情.

更新：我们已经使用Nagios进行监控,这对于检测到的主机/测试服务/等非常有用,但对于抓取日志文件则不太有用.我知道有Nagios的日志插件,但我对比每个主机警报更具可扩展性和层次性的东西感兴趣.