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的日志插件,但我对比每个主机警报更具可扩展性和层次性的东西感兴趣.
解决方法
> Syslog / syslog-ng转发到一个主机
> Zenoss用于聚合和提醒事件
> Splunk用于日志聚合和搜索
对于#3,我通常使用syslog-ng将来自每个主机的消息直接转发到splunk.它也可以直接解析日志文件,但这可能有点痛苦.
Splunk非常适合搜索和分类日志.我没有使用splunk进行日志警报,但我认为这是可能的.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。