首先感謝孔峰同志贈書，讓我能夠對nagios這個世界級的開源監控產品有了一個系統級的認識。

對于一個曾經的運維，監控系統會變成夜夜狼嚎，讓人無法安睡，是深有體會。一個好的監控系統尤為重要，nagios這個應用是如何解決這個問題呢？我理解應該是采用眾創的方式，但這種眾創的方式有點像免費游戲，每個使用者又是免費玩家，你可以通過自己的勤奮練級（編碼），打怪（集成插件）來定制一套符合自己的監控系統。

所以，nagios推崇的不是一次性整體的解決方案，而是與其他開源工具互操作，組合完成。作者認為：現實中大多數商業軟件的產品方向，他們解決問題的方式是假設所有人都希望采用相同的解決方案（注：可復制性是商業軟件的盈利基礎。商業的解決方案目前也趨向于自助選擇按需服務，但是與nagios這樣的產品由用戶創造內容還差距較大）。商業軟件希望通過一站式解決方案滿足所有監控需求，這就造成不斷的監控代碼加入到了監控軟件，逐漸也就形成了一份龐大的監控功能清單。

監控系統的構建需要能夠有效的與環境中的其他系統交互，要適用于各種客戶，包括菜鳥和專家。監控平臺的構建不僅僅需要技術能力，還需要精心的規劃、全局的視角以及良好的人際溝通技巧。可能很重要的是，所構建的系統不能對現有系統影響。拙略的監控系統不僅會占用網絡、系統資源、還會產生安全問題，甚至會影響到新人他的運維人員。“首先，不要帶來傷害”。

下面這個案例是一個典型的監控所帶來的的問題，或者不合理的監控s帶來的一種變向傷害：

**經理：你把我加入監控系統中，我想接收所有系統的警告消息。

管理員：所有的？

經理：是的，所有的警告消息。

管理員：呃，好的。

------第二天

經理 ：昨晚傳呼機響個不停，害我一夜沒合眼，這意味著什么？

管理員：哦，服務器I的/var分區滿了，連接站點site5的VPN隧道時斷時續。

經理：你就不能通知我實際的問題？

管理員：這就是實際的問題。**

并不是說管理員需要服務器1 的/var分區滿了的時候發出告警，而說在收到通知的時候，他應該明白了通知的什么以上，管理層是希望立刻修復還是明天再說？還應該通知誰呢？如果他不響應會發生什么？這種完備的信息對管理層抉擇是非常有幫助的，只有明確的定義問題的構成，管理層才能給出自己的意見。監控系統應該執行組織的制度，而非僅僅將問題反應處理來，如果組織需要有人能夠10分鐘內查看服務器1的所有問題，那么監控系統應當給我們的管理員明確提供指示（比如優先級），確認告警消息的機制以及告警的自動升級（例如超出10分鐘自動通知他人）。

監控規劃過程中，關鍵系統是有運營公司的管理層確定的，有點類似于災難恢復順序，當所有IT系統崩潰時，恢復的順序應該是監控的優先級的順序。獲得關鍵系統順序后，各專業系統的不同組件順序的優先級應該由專業系統的管理員給出定義。

建立減少監控系統到監控目標的三層路由，避免對路由決策的依賴。避免擁塞阻塞，例如部署再內網的監控主機，監控主機在防火墻故障時候無法監控dmz區域設備。一般解決的方法是在監控主機上增加網卡，完成兩個網段的監控。（減少監控過程中的黑洞，避免影響監控數據的傳遞路徑。）

nagios 遵循UNIX哲學：”只做一件事，并把它做好“、沉默是金（合適的監控力度，不能太多，也不能太少）；監控閾值應該跟隨環境的變化，例如CPU閾值70%，但新增了一個批量執行腳本，再中午時段會引起75%的占用率，這種情況下應該優化閾值，對于羽翼未豐的監控系統大量誤報會削弱可信度；設置通知時需要考慮聯系人的關系，例如DBA 不會關心主機的CPU利用率過高。

優秀的監控系統是專注的而非泛泛。他們監控了許多服務以滿足分析需求，但是很少發出通知，而且只發送給想知道的那群人。而對于求知欲很強的人而已，為避免他們全天關機，只能每天定時給他們發送匯總或者摘要。端到端監控可以看到系統存在問題，但是問題的原因卻無法反應出來。例如：不出郵件，是因為DNS故障造成的。

監控系統需要一條用于監控自己本身的規則，只需要知道監控系統不宕機即可。監控服務器的作用是通過不同協議與其他系統的交互，以便獲得監控結果。

nagios是一個優雅的程序，簡單易懂。它能夠以用戶期望的方式完成用戶期望的工作，而且還能擴展出一些驚人的事件。Nagios 能夠發揮個人的技術能力，你為了更好的集中化他們的監控工具二花了五個月，通過一個免費的監控平臺而實現，這會體現個人價值，并讓組織看到并重視你。（注：系統的人性****！管理員的價值！）

nagios主要監控的對象是主機和服務，主機是一切可以進行TCP通信的東西，包括傳感器、冰箱等。服務這是由主機提供的邏輯實體，例如守護進程。一個主機會有多個應用被監視，但是主機本身只有啟動或者宕機兩個狀態。Nagios對于每臺主機設定唯一的監測機制以及多個服務監測，例如定義check_ping 定義為主機檢測，如果檢測失敗則主機down，對應的所有主機檢測服務也不可用。

依賴關系

對于不同主機之間的相互依賴關系有兩種，父子關系、，如果父節點down后則子節點的主機不再進行監測。例如防火墻宕機后，防火墻后的服務器1則認為不可達。nagios則不會再去監測主機1和主機1上的服務。依賴關系的定義監測的依賴關系，例如 某臺設備的web服務依賴與代理服務器的WEB服務，如果nagios監測到代理服務器的nagios服務失敗，則不會監測所以web服務。（個人理解，例如tomcat down 就不會監測web服務）。 nagios對于服務和主機的定義在集群環境下的使用略顯不足，主要依靠其他插件完成。

插件：nagios 是一個調度和通知的框架，通過調用成為插件的小型監控程序工作。

退出代碼機制（感覺應該翻譯為返回碼），nagios 對于一切可以提供退出代碼的語言都進行支持，共計支持 0 1 2 3 ，分別代表 正常、警告、嚴重、未知 4種監控結果。nagios根據這些狀態碼進行反應，決定是否通知誰。（注，從這個機制看IFTTT? 這個服務和nagios很像， If this then that-如果這樣就怎樣。根據不同狀態做判斷）。 nagios 的的所有調度包括主機和服務的檢測，他們都位于一個全局事件隊列中，但是并不嚴格控制絕對的時間，而是通過兩個選線組合定義出了了時間間隔，間隔長度、重試間隔。nagios 通過交錯因子完成檢測的分散負載，部門所有業務檢測都集中再一臺服務器上。

數據采集包括兩種類型，可以并發執行和不能并發執行的。nagios中的服務檢測都是可以并發執行的。信息采集事件相當于nagios的心跳，無理論插件執行多快，只要沒有出現采集事件，nagios就不會處理這個插件。

通知，如果沒有配置過，則每次狀態改變nagios都會發出通知，或者是donw足夠長后再發送出一次通知。全局通知的啟用后，nagios就會進入程序持久化的狀態，確保nagios能夠保留當期各檢測服務的狀態。通知選項，主機主要包括：不可達、宕機、恢復、震蕩，服務則包括：未知、嚴重、警告、恢復、震蕩。聯系人用于設定通知的對象。

模板，可以讓定義進行復制，減少文字輸入時間。時間段，包括通知發送時間區間和服務檢測時間區間。nagios不僅僅是監控系統，更是一套信息收集程序。計劃宕機事件、狀態確認及升級規則。

作為一本工具書文中也詳細描述了nagios的部署以及各種插件集成過程，切實網上也有不少入門教程，相對作者的更易懂，但作者的更為系統和全面。

nagios與商業產品相交互落伍（語法難用），界面太復古，沒有時序數據，缺少數據庫等等，對于商業用戶，他們不愿意百鳥在林（在選擇開源插件），更愿意一鳥在手（可靠的解決問的服務）。