对于许多 IT 和运维团队来说,Nagios 既是一个福音也是一个诅咒。一方面,Naigos 在 IT 应用的工作领域中,给予了你可以实时查看告警数据的可能性;但是另一方面, Nagios 也能够生成超级多的告警,对于任何一个运维人员或是运维团队来说都是 hold 不住的。
由于告警浪潮的原因,我们收件箱时常会爆满,移动电话也会被逼调成静音状态。更令人沮丧的是,这些告警只不过仅仅是噪音而已。
Nagios 所欠缺的就是一个智能的管理系统,可以在噪音背景中,帮助运维人员挑选出真正的有意义的告警。
当然,说起来容易做起来难。
在上一篇文章中,我们讨论了为什么 Naigos 起初会生成如此之多的告警,并且很少是需要实际执行的。
那么现在,让我们来讨论下该如何把告警智能化。
唯一使监控和报警都步入正轨的好办法,就是通过告警关联。如果成百上千个告警都潜在的指向着同一个根本问题「当然情况也常常如此」,我们需要的就是一种能够瞬间查找到关联这些告警的方法,这才是真正的问题所在。
以下这个例子,可以很好的理解告警关联,并告诉你如何提升应用监控。
例如一个 MySOL 集群,这里面一些主机的页面上有着很高的错误率,而其余一些只是发出低内存的警告。此时你的 Nagios 图表盘在30分钟里,会接受到不止20个独特的告警,这其实看起来没有太大的意义。你的电子邮件收件箱看起来就像一个垃圾桶,并且当你离开办公室以后,你口袋里的移动电话还会嗡嗡的响。
我们可以用一个正确的方式和一个错误的方式来分别处理这些告警。错误的方式就是将所有这些告警都作为单一的独立信息,而不是把这些警告看做是一个完整事件的代表。这样当告警洪潮来临的时候,我们根本无法寻找到这个发起者。
而正确的方法则是,透过图表盘的数据来看这些报警关联的特征,整条告警潮流可能都会被组合在一起。所有这些集群的页面错误告警都将被聚合,指出真正的根源所在,并且会一直在我们的掌控中,即使被告警浪潮淹没也不怕。
除了没有关联性质的「比如在 MySQL 节点上的一个存储问题」事件,大部分的告警都可以被整合收集在一起。我们可以轻易的归类这些告警信息,并跟其他的类似事件划分开。这样在一个告警洪流中,被湮灭的将会是其他无意义的告警了。
告警关联是一个分组的方法,有着高度相关联的一系列告警信息,就会被分为一个高级事件。
还有其他方法可以对抗告警洪潮吗?有是有,但它们都很无用。
一个通常被用于企业的方法,就是告警过滤。监控工程师自己配置的图表盘,仅局限于少量的警报,指定为高安全性的警报。可预计的到,这样的图表盘将比一个完整的图表盘会大大的减少告警噪音。
但是,这里有三个关于告警过滤的问题不容忽视。首先,它在你的操作可视化上创造了一个盲点,这样会使问题癌变,因为通常情况下,低程度的告警是高程度告警的前提。例如,一个 CPU 负载事件可能很快就会演变成一个全面的故障。
通过忽视掉低程度的问题,你强迫自己进入一个只操作高程度告警的反应模式。此时你已经背离了告警监控的初衷了———接收告警的目的是在他们急剧上升之前就能够解决掉潜在的问题。然而,告警过滤经常是完全相反地,因为低程度的事件会被积极的开除的,等到潜在的威胁已经影响到了用户以后,风险报警才会对团队做出响应。
第二个问题是关于过滤本身的,过滤后图表盘上的信息会变更得非常的简单且难以捉摸。以上面 MySQL 为例,在你的高严重报表的仪表盘中,要了解到所有的页面故障率是不现实的。因此,当你消除掉低内存的告警后,你的肩上依然有可能背负着其余的有效告警。
最后也是最主要的问题,就是这种过滤的设定只能锁定已知的问题。如果一个新的高风险事件出现,将会被过滤器无情的回避忽视掉,从而无法被归类到既定的图表盘中去查看与处理。
相比之下,告警关联可以使你很好的抵抗告警洪潮,也不会丢失问题的可见性。企业如果适应了告警关联,信息告警的图表盘上确实能减少很多压力。
在 Onealert 中,我们开发了一个基于云端的分布式现代化告警关联性平台,并且我们还优化了与 Nagios 等一系列开源监控工具的集成。
Onealert 能够集成你的 Nagios 告警,它会用一个智能算法,来处理和关联这些告警。整个 Onealert 图表盘是一个基于云端的应用服务,代表着所有 Nagios 告警,可以有效地组合成高层次的事件。
然而你也不必要完全相信我的话,咱们可以尝试着自己安装下 Onealert ,学习更简单的生活,使你的工作也在无穷无尽的告警中变得更有意义。