若是你受困於 Nagios 的告警洪潮中不能自拔,那麼這兩篇連載博客就是爲你而生的。讓咱們來詳細的闡述下這個問題!ios
運維人員都有着獨立的監控工具,所以會常常受到 Nagios 告警吵鬧的影響。不少運維人員對 Nagios 都是愛恨交加的,Nagios 給了你實時的可見性,能夠了解你的 IT 基礎設施的內部運做。用 Naigos,你能夠辨認出哪一臺主機內存不足,哪臺服務器會佔用太多 CPU 週期,哪個應用因爲訪問時間太長而跳轉離開。你也可以足夠早的獲得告警信息,在他們影響最終用戶以前解決掉問題,最大限度的讓 Nagios 爲你而戰。服務器
######埋在乾草堆裏的針運維
然而這些都是理論上的,不難發現,Nagios 最終致使的問題跟它解決掉的問題實際上是同樣多的。讓咱們退一小步來說,Nagios 實際上並不會引發問題,只是它會使運維團隊鑑別出真正的問題時更加困難。舉個例子,當小孩子哭鬧時,並不必定是真的作錯了什麼,他們只是想被關注,或是由於他們經驗有限,沒法處理一件微不足道的小事,而在他們看來這倒是一個大大的問題,因此會使勁兒的哭。做爲父母,咱們知道摔傷的膝蓋只須要一個創可貼,但在疼痛來臨的那一刻,你的孩子會認爲他可能永遠沒法再走路了。jsp
處理 Nagios 告警就像哄一個哭泣的孩子同樣,從外觀上看,咱們並無什麼好的方法可以輕鬆區分一個摔傷的膝蓋和一個折斷的腿。由於 Nagios(實際上也是大多數監控系統的通病)的每個告警都看起來像即將到來的重大問題,又或者只是一個日常的小事而已。所以即使父母近乎一瞬間就會知道,他們手上有一個亟需處理的問題須要解決,但關鍵是咱們並不能區分這鱷魚的眼淚是真是假。工具
######自動化監控 這裏我須要問兩個重要的問題:爲何洪水警惕會一直髮生?而且爲何會愈演愈烈?人工智能
問題的根源實際上是基於告警監控的積極一面:自動化。沒有任何一個運維人員,甚至是整個運維團隊,可以手動解析成千上萬個數據,用來查明問題。沒有人會要求運營團隊時刻盯着圖表去指出隨時出現的問題所在。事件
因此,咱們對 Nagios 配置好閾值,並把這項艱鉅的工做委派給它。而後 Nagios 會經過咱們設定好的全部的監控去尋找超過閾值的事件,並向咱們報告。內存
說到這裏,發現問題了嗎?開發
純自動化終歸不如人工智能,窗戶打開了,新鮮空氣伴隨着蒼蠅蚊子都會進來。最終的結果會比你想象的直接得多:設定的這種配置,會把咱們埋葬在浪潮般的告警洪流中,這就是 Nagios 所作的事情。get
那麼如何解決這個左右爲難的問題呢?首先咱們先列出問題點都有哪些:
一、沒法辨認 現代的應用已經再也不是單單獨立的個體了,它再也不依賴於一個強大的服務器,相反它能夠從防火牆、服務器直接上升到雲層共享,它可能依賴於數10、甚至成百上千個服務器支持着。因此當應用程序遇到問題時,咱們獲得的是數以百計的警報,而且每每都指向同一個原因,即便它們看起來像一個單獨的問題。
二、關聯性 在過去的十年中,單一的應用之間由於許多共同的服務而彼此互通着,這一問題將隨着時間的推移而變得更加明顯,愈來愈多的開發者會創造更多的應用程序。這使得公司發展的很快,而對應的擴展性,關聯穩定性和可維護性卻日趨上演成了主角。
這也就意味着,一個單一的問題可能會影響到多個服務器,在一個服務器上的問題,也可能會逐步升級到鄰近的應用層面,逐漸從幾十個服務器中創造一系列告警。
然而,哪個服務器是根源?在一個巨大的告警洪流中,它是不可能區分出來的。
三、快節奏的時代 在這個快節奏的時代,工程師團隊必須調整他們的目標與頂層的業務相結合。這種轉變意味着,咱們如今會愈來愈少的看到長達幾年之久的,在學術上很是靚麗的研發。開發人員經過吸取客戶的反饋指導,會選擇短平快的項目。不幸的是,這影響了咱們保持準確和最新監控配置的能力。當咱們完成配置的閾值和分類的時候,咱們的應用已經變了。隨着時間的推移,咱們積累了大量無心義的監測或者過期的閾值數據。
而後,你可以區分出這些遺留的噪音哪些是應該被忽視的,哪些是能夠制止的,哪些又是會致使宕機的亟需待解決的問題嗎?
的確,配置實時的監控閾值是一項很是重要的工做,但不幸的是,咱們的監控告警系統壓根兒跟不上時代的變遷。
######那麼,是時候引出新概念了。用科學的數據,馴服 Nagios。 Onealert 智能告警監控能夠把你的 Nagios 告警關聯到任一高層事件,所以你能更快的辨認出關聯性的問題,而不是人工去涉足數以千計的 Nagios 告警洪流,你如今可以以統一的標準來檢閱它們,清晰的從噪音中分離出有意義的信號。這就是運維團隊所須要的辨認關鍵性信息的能力,關聯告警的能力,跟上快節奏時代的能力。
離開 Onealert 會讓你受到威脅,配置錯誤,宕機等一系列問題,由於真正的解決方案已經埋葬在了告警浪潮之中。