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