如果你受困于 Nagios 的告警洪潮中不能自拔，那么这两篇连载博客就是为你而生的。让我们来详细的阐述下这个问题！
运维人员都有着独立的监控工具，因此会经常受到 Nagios 告警吵闹的影响。很多运维人员对 Nagios 都是爱恨交加的，Nagios 给了你实时的可见性，可以了解你的 IT 基础设施的内部运作。用 Naigos，你可以辨认出哪一台主机内存不足，哪台服务器会占用太多 CPU 周期，哪一个应用由于访问时间太长而跳转离开。你也能够足够早的得到告警信息，在他们影响最终用户之前解决掉问题，最大限度的让 Nagios 为你而战。
埋在干草堆里的针
然而这些都是理论上的，不难发现，Nagios 最终导致的问题跟它解决掉的问题其实是一样多的。让我们退一小步来讲，Nagios 实际上并不会引起问题，只是它会使运维团队鉴别出真正的问题时更加困难。举个例子，当小孩子哭闹时，并不一定是真的做错了什么，他们只是想被关注，或是因为他们经验有限，无法处理一件微不足道的小事，而在他们看来这却是一个大大的问题，所以会使劲儿的哭。作为父母，我们知道摔伤的膝盖只需要一个创可贴，但在疼痛来临的那一刻，你的孩子会认为他可能永远无法再走路了。
处理 Nagios 告警就像哄一个哭泣的孩子一样，从外观上看，我们并没有什么好的方法能够轻松区分一个摔伤的膝盖和一个折断的腿。因为 Nagios（实际上也是大多数监控系统的通病）的每一个告警都看起来像即将到来的重大问题，又或者只是一个平常的小事而已。因此即便父母近乎一瞬间就会知道，他们手上有一个亟需处理的问题需要解决，但关键是我们并不能区分这鳄鱼的眼泪是真是假。
自动化监控
这里我需要问两个重要的问题：为什么洪水警戒会一直发生？并且为什么会愈演愈烈？
问题的根源其实是基于告警监控的积极一面：自动化。没有任何一个运维人员，甚至是整个运维团队，能够手动解析成千上万个数据，用来查明问题。没有人会要求运营团队时刻盯着图表去指出随时出现的问题所在。
所以，我们对 Nagios 配置好阈值，并把这项艰巨的工作委派给它。然后 Nagios 会通过我们设定好的所有的监控去寻找超过阈值的事件，并向我们报告。
说到这里，发现问题了吗？
纯自动化终归不如人工智能，窗户打开了，新鲜空气伴随着苍蝇蚊子都会进来。最终的结果会比你想象的直接得多：设定的这种配置，会把我们埋葬在浪潮般的告警洪流中，这就是 Nagios 所做的事情。
那么如何解决这个左右为难的问题呢？首先我们先列出问题点都有哪些：
1、无法辨认
现代的应用已经不再是单单独立的个体了，它不再依赖于一个强大的服务器，相反它可以从防火墙、服务器直接上升到云层共享，它可能依赖于数十、甚至成百上千个服务器支持着。所以当应用程序遇到问题时，我们得到的是数以百计的警报，并且往往都指向同一个缘由，即使它们看起来像一个单独的问题。
2、关联性
在过去的十年中，单一的应用之间因为许多共同的服务而彼此互通着，这一问题将随着时间的推移而变得更加明显，越来越多的开发者会创造更多的应用程序。这使得公司发展的很快，而对应的扩展性，关联稳定性和可维护性却日趋上演成了主角。
这也就意味着，一个单一的问题可能会影响到多个服务器，在一个服务器上的问题，也可能会逐步升级到邻近的应用层面，逐渐从几十个服务器中创造一系列告警。
然而，哪一个服务器是根源？在一个巨大的告警洪流中，它是不可能区分出来的。
3、快节奏的时代
在这个快节奏的时代，工程师团队必须调整他们的目标与顶层的业务相结合。这种转变意味着，我们现在会越来越少的看到长达几年之久的，在学术上非常靓丽的研发。开发人员通过吸收客户的反馈指导，会选择短平快的项目。不幸的是，这影响了我们保持准确和最新监控配置的能力。当我们完成配置的阈值和分类的时候，我们的应用已经变了。随着时间的推移，我们积累了大量无意义的监测或者过时的阈值数据。
然后，你能够区分出这些遗留的噪音哪些是应该被忽视的，哪些是可以制止的，哪些又是会导致宕机的亟需待解决的问题吗？
的确，配置实时的监控阈值是一项非常重要的工作，但不幸的是，我们的监控告警系统压根儿跟不上时代的变迁。
那么，是时候引出新概念了。用科学的数据，驯服 Nagios。
Onealert 智能告警监控可以把你的 Nagios 告警关联到任一高层事件，因此你能更快的辨认出关联性的问题，而不是人工去涉足数以千计的 Nagios 告警洪流，你现在能够以统一的标准来检阅它们，清晰的从噪音中分离出有意义的信号。这就是运维团队所需要的辨认关键性信息的能力，关联告警的能力，跟上快节奏时代的能力。
离开 Onealert 会让你受到威胁，配置错误，宕机等一系列问题，因为真正的解决方案已经埋葬在了告警浪潮之中。
