如何把关联性的告警智能添加到 Nagios 上？（2）

对于许多 IT 和运维团队来说，Nagios 既是一个福音也是一个诅咒。一方面，Naigos 在 IT 应用的工作领域中，给予了你可以实时查看告警数据的可能性；但是另一方面，Nagios 也能够生成超级多的告警，对于任何一个运维人员或是运维团队来说都是 hold 不住的。

由于告警浪潮的原因，我们收件箱时常会爆满，移动电话也会被逼调成静音状态。更令人沮丧的是，这些告警只不过仅仅是噪音而已。

Nagios 所欠缺的就是一个智能的管理系统，可以在噪音背景中，帮助运维人员挑选出真正的有意义的告警。

当然，说起来容易做起来难。

在上一篇文章中，我们讨论了为什么 Naigos 起初会生成如此之多的告警，并且很少是需要实际执行的。

那么现在，让我们来讨论下该如何把告警智能化。
如何把关联性的告警智能添加到Nagios上？

唯一使监控和报警都步入正轨的好办法，就是通过告警关联。如果成百上千个告警都潜在的指向着同一个根本问题「当然情况也常常如此」，我们需要的就是一种能够瞬间查找到关联这些告警的方法，这才是真正的问题所在。

以下这个例子，可以很好的理解告警关联，并告诉你如何提升应用监控。

例如一个 MySOL 集群，这里面一些主机的页面上有着很高的错误率，而其余一些只是发出低内存的警告。此时你的 Nagios 图表盘在30分钟里，会接受到不止20个独特的告警，这其实看起来没有太大的意义。你的电子邮件收件箱看起来就像一个垃圾桶，并且当你离开办公室以后，你口袋里的移动电话还会嗡嗡的响。

我们可以用一个正确的方式和一个错误的方式来分别处理这些告警。错误的方式就是将所有这些告警都作为单一的独立信息，而不是把这些警告看做是一个完整事件的代表。这样当告警洪潮来临的时候，我们根本无法寻找到这个发起者。

而正确的方法则是，透过图表盘的数据来看这些报警关联的特征，整条告警潮流可能都会被组合在一起。所有这些集群的页面错误告警都将被聚合，指出真正的根源所在，并且会一直在我们的掌控中，即使被告警浪潮淹没也不怕。

除了没有关联性质的「比如在 MySQL 节点上的一个存储问题」事件，大部分的告警都可以被整合收集在一起。我们可以轻易的归类这些告警信息，并跟其他的类似事件划分开。这样在一个告警洪流中，被湮灭的将会是其他无意义的告警了。

告警关联是一个分组的方法，有着高度相关联的一系列告警信息，就会被分为一个高级事件。

还有其他方法可以对抗告警洪潮吗？有是有，但它们都很无用。

一个通常被用于企业的方法，就是告警过滤。监控工程师自己配置的图表盘，仅局限于少量的警报，指定为高安全性的警报。可预计的到，这样的图表盘将比一个完整的图表盘会大大的减少告警噪音。

但是，这里有三个关于告警过滤的问题不容忽视。首先，它在你的操作可视化上创造了一个盲点，这样会使问题癌变，因为通常情况下，低程度的告警是高程度告警的前提。例如，一个 CPU 负载事件可能很快就会演变成一个全面的故障。

通过忽视掉低程度的问题，你强迫自己进入一个只操作高程度告警的反应模式。此时你已经背离了告警监控的初衷了———接收告警的目的是在他们急剧上升之前就能够解决掉潜在的问题。然而，告警过滤经常是完全相反地，因为低程度的事件会被积极的开除的，等到潜在的威胁已经影响到了用户以后，风险报警才会对团队做出响应。

第二个问题是关于过滤本身的，过滤后图表盘上的信息会变更得非常的简单且难以捉摸。以上面 MySQL 为例，在你的高严重报表的仪表盘中，要了解到所有的页面故障率是不现实的。因此，当你消除掉低内存的告警后，你的肩上依然有可能背负着其余的有效告警。

最后也是最主要的问题，就是这种过滤的设定只能锁定已知的问题。如果一个新的高风险事件出现，将会被过滤器无情的回避忽视掉，从而无法被归类到既定的图表盘中去查看与处理。

相比之下，告警关联可以使你很好的抵抗告警洪潮，也不会丢失问题的可见性。企业如果适应了告警关联，信息告警的图表盘上确实能减少很多压力。

在 Onealert 中，我们开发了一个基于云端的分布式现代化告警关联性平台，并且我们还优化了与 Nagios 等一系列开源监控工具的集成。

Onealert 能够集成你的 Nagios 告警，它会用一个智能算法，来处理和关联这些告警。整个 Onealert 图表盘是一个基于云端的应用服务，代表着所有 Nagios 告警，可以有效地组合成高层次的事件。

然而你也不必要完全相信我的话，咱们可以尝试着自己安装下 Onealert，学习更简单的生活，使你的工作也在无穷无尽的告警中变得更有意义。