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

對於許多 IT 和運維團隊來說，Nagios 既是一個福音也是一個詛咒。一方麵，Naigos 在 IT 應用的工作領域中，給予了你可以實時查看告警數據的可能性；但是另一方麵，Nagios 也能夠生成超級多的告警，對於任何一個運維人員或是運維團隊來說都是 hold 不住的。

由於告警浪潮的原因，我們收件箱時常會爆滿，移動電話也會被逼調成靜音狀態。更令人沮喪的是，這些告警隻不過僅僅是噪音而已。

Nagios 所欠缺的就是一個智能的管理係統，可以在噪音背景中，幫助運維人員挑選出真正的有意義的告警。

當然，說起來容易做起來難。

在上一篇文章中，我們討論了為什麼 Naigos 起初會生成如此之多的告警，並且很少是需要實際執行的。

那麼現在，讓我們來討論下該如何把告警智能化。

唯一使監控和報警都步入正軌的好辦法，就是通過告警關聯。如果成百上千個告警都潛在的指向著同一個根本問題「當然情況也常常如此」，我們需要的就是一種能夠瞬間查找到關聯這些告警的方法，這才是真正的問題所在。

以下這個例子，可以很好的理解告警關聯，並告訴你如何提升應用監控。

例如一個 MySOL 集群，這裏麵一些主機的頁麵上有著很高的錯誤率，而其餘一些隻是發出低內存的警告。此時你的 Nagios 圖表盤在30分鍾裏，會接受到不止20個獨特的告警，這其實看起來沒有太大的意義。你的電子郵件收件箱看起來就像一個垃圾桶，並且當你離開辦公室以後，你口袋裏的移動電話還會嗡嗡的響。

我們可以用一個正確的方式和一個錯誤的方式來分別處理這些告警。錯誤的方式就是將所有這些告警都作為單一的獨立信息，而不是把這些警告看做是一個完整事件的代表。這樣當告警洪潮來臨的時候，我們根本無法尋找到這個發起者。

而正確的方法則是，透過圖表盤的數據來看這些報警關聯的特征，整條告警潮流可能都會被組合在一起。所有這些集群的頁麵錯誤告警都將被聚合，指出真正的根源所在，並且會一直在我們的掌控中，即使被告警浪潮淹沒也不怕。

除了沒有關聯性質的「比如在 MySQL 節點上的一個存儲問題」事件，大部分的告警都可以被整合收集在一起。我們可以輕易的歸類這些告警信息，並跟其他的類似事件劃分開。這樣在一個告警洪流中，被湮滅的將會是其他無意義的告警了。

告警關聯是一個分組的方法，有著高度相關聯的一係列告警信息，就會被分為一個高級事件。

還有其他方法可以對抗告警洪潮嗎？有是有，但它們都很無用。

一個通常被用於企業的方法，就是告警過濾。監控工程師自己配置的圖表盤，僅局限於少量的警報，指定為高安全性的警報。可預計的到，這樣的圖表盤將比一個完整的圖表盤會大大的減少告警噪音。

但是，這裏有三個關於告警過濾的問題不容忽視。首先，它在你的操作可視化上創造了一個盲點，這樣會使問題癌變，因為通常情況下，低程度的告警是高程度告警的前提。例如，一個 CPU 負載事件可能很快就會演變成一個全麵的故障。

通過忽視掉低程度的問題，你強迫自己進入一個隻操作高程度告警的反應模式。此時你已經背離了告警監控的初衷了———接收告警的目的是在他們急劇上升之前就能夠解決掉潛在的問題。然而，告警過濾經常是完全相反地，因為低程度的事件會被積極的開除的，等到潛在的威脅已經影響到了用戶以後，風險報警才會對團隊做出響應。

第二個問題是關於過濾本身的，過濾後圖表盤上的信息會變更得非常的簡單且難以捉摸。以上麵 MySQL 為例，在你的高嚴重報表的儀表盤中，要了解到所有的頁麵故障率是不現實的。因此，當你消除掉低內存的告警後，你的肩上依然有可能背負著其餘的有效告警。

最後也是最主要的問題，就是這種過濾的設定隻能鎖定已知的問題。如果一個新的高風險事件出現，將會被過濾器無情的回避忽視掉，從而無法被歸類到既定的圖表盤中去查看與處理。

相比之下，告警關聯可以使你很好的抵抗告警洪潮，也不會丟失問題的可見性。企業如果適應了告警關聯，信息告警的圖表盤上確實能減少很多壓力。

在 Onealert 中，我們開發了一個基於雲端的分布式現代化告警關聯性平台，並且我們還優化了與 Nagios 等一係列開源監控工具的集成。

Onealert 能夠集成你的 Nagios 告警，它會用一個智能算法，來處理和關聯這些告警。整個 Onealert 圖表盤是一個基於雲端的應用服務，代表著所有 Nagios 告警，可以有效地組合成高層次的事件。

然而你也不必要完全相信我的話，咱們可以嚐試著自己安裝下 Onealert，學習更簡單的生活，使你的工作也在無窮無盡的告警中變得更有意義。

最後更新：2017-04-01 13:44:33