Nagios 郵箱告警的方式太OUT了！

通常來說，在安裝完 Nagios 後，咱們作的第一件最正確的事，就是設置它的郵件通知，對吧。由於若是沒有這一步驟的話，你怎麼可以知道何時會出現問題呢？

伴隨着成功的初始安裝，你即將是你司惟一一個可以接收到告警數據的人。Nagios 的一個很好的功能就是能夠監控到不一樣的服務器。人生如夢，這種蜜月期並不會持續過久，很快事情就會從很好處理變得開始難以操縱，等到你意識到已爲時晚矣———天天都會有幾十個甚至上百個告警鋪天蓋地的蜂擁而至。你試圖去理清這些永無休止、有如浪潮般的告警郵件，但依然是剪不斷，理還亂......

說實話，告警信息真不必非得弄得諸如此般狼狽不堪的模樣。如下列出了關於有效告警的幾個方面，而且告訴你們 Nagios 郵箱告警的不可取之處。

######請注意，告警信息都是動態的，即並不是是靜態的一成不變的

當這些告警信息以電子郵件的方式進入到你的郵箱後，它們就不會再發生改變了，然而現實中的告警倒是無時無刻的不在變化。這意味着你將會每一刻都收到狀態發生了改變的告警電子郵件，致使你查看郵件時很難搞清哪個告警纔是當下發生的。這時候小夥伴兒們就該說了，解決此類問題很簡單啊，只單單查看最近時間的一些告警郵件便可，說的簡單，同志們，試想一下，你登錄郵箱後成百上千封郵件撲面而來，你從中很快速的篩選出離得最近的有效告警郵件，而且這些告警偏偏可以把你係統出現的全部問題都涵蓋到，而且去一一解決，作到無一遺漏，現實嗎？

######應用性能管理告警壓縮

Nagios 是基於服務器和主機形式的告警監控，這就意味着，若是一臺服務器有多項問題，那麼每個問題都會對應發送出一個相關的郵件。你只能本身經過界定他們之間的依賴關係，來嘗試解決告警問題。在現代化環境中，咱們發出的更多的是應用性能管理告警，而並非特定的服務器或是主機。

例如，在一百臺服務器中，若是隻有一臺出了問題，碰巧除此以外其他全部的服務器都在如期的正常工做中，咱們就用不着整晚都在修復中度過了。而若是有五十臺服務器宕了，那就是很是嚴重的報警了，但咱們一會兒也處理不了五十個告警呀。所以，咱們更習慣於只接受到有關應用層面的一個壓縮告警，告訴我有多少服務器受到了影響，又有多少服務器依然是在正常的運行中，好讓我可以對當下出現的問題一目瞭然。

######告警分析

一般狀況下，在解決告警或者徹底弄懂告警的問題上，告警信息的監控其實並不到位。好比我如今手頭上有一個問題，那麼每每獲得更多的告警信息纔可以大幅度地減小解決這個問題的時間。

例如，一臺服務器超負荷了，若是咱們能看到最近幾小時的 CPU 圖表，而且能瞭解到應對此問題作出高級指令後的執行結果，會對咱們解決告警起到相當重要的做用。這些徹底能夠用 OneAlert 的分析功能來實現，但這僅僅這也是該功能的冰山一角。若是你還能看到這個問題發生時的最近告警事件的柱狀圖，又或者是在這一段時間中，發生在你的系統中全部信息的一系列變化，包括告警事件次數、平均確認時間、平均解決時間等，會不會是超讚的呢？

######可控的

單單獲取內容是不夠的，好比如今，當我收到一個告警的時候，介於我正在忙其餘更重要的事情，我想指派給某人來處理此告警，又或者是這個報警自己就應該由相應的人來處理，系統必須正確的把報警信息指派給特定的人，該怎麼辦呢？更深一層次的說，咱們須要有大量的可控化操做，好比勘察記錄、人工指派、逐層分級以及解決問題的分享等。

######團隊協做

一個團隊若是可以很好的互相協做，會使得不少事情變得很好解決，但團隊中處理 Nagios 的郵件報警有的時候真的是很痛苦。讓咱們來看一看那些堆積郵件如山的郵箱吧，你怎麼知道是否有人已經作出了正確的答覆？你又該如何快速的將一個告警，開放式的分配指派給他人，又或者請教他人解決的方式呢？你可以看到團隊其餘成員關於某一事件的最後一次告警做出的詳細筆錄嗎？這些看似簡單的問題，對於郵箱告警來講基本不可能實現。

Nagios 很難制定人性化的程序。咱們知道，只有得益於一些插件和先進的配置的幫助，問題纔會獲得更好的解決。把控系統的全部可能性，而且持續的維護它們是 OneAlert 的使命。僅僅舉幾個例子：告警壓縮、告警分析、指派分配、告警記錄、團隊分享等太多太多了……那麼問題來了，你應該如何開始管理你的監控系統？

OneAlert 專一於解決處理以上全部的痛點，不要驚奇，想來了解一下嗎？如今還能夠免費體驗，趕快行動吧！