在監控的世界裡，存在太多不可預知性（當然，在當下這個世界裡，存在太多不可預知性。也成立:-)），因為監控的物件總是在不斷的更新（摩爾定理）。Nagios在設計其架構的時候，充分考慮到了變化這個因素，把可變的與不變的部分隔離，讓可變的部分可以定製，可二次開發。

當然，不變與可變分離，這個原則很容易理解，但是要實施起來併成功，並不是那麼容易。一個好的架構並不是完全設計出來的，最終看到的好的架構，是設計＋演進共同達到的。

架構的設計固然十分重要，架構設計是針對軟體需要解決問題領域的分析，結合其未來存在的彼變化，給出的一個解決方案。

如果設計錯了，就是說問題沒有分析清楚，那當然解決不了問題，軟體註定是失敗的。
但是如果設計沒問題，那麼最終開發出來的軟體架構也不一定就是沒問題的。因為世界總是在變化，架構設計出來只是一個靜態的結構，在面對新的變化，需要不斷的演進。如果演進的不好，那麼最終架構也不是一個好架構。

我們套用熵定律，隨著時間的流逝熵總是不斷增加的（不會減少），那麼架構的熵也是如此，我們把架構演進稱為架構的逆熵，那麼一個好的架構就是不斷的逆熵結果。

說了這麼多廢話，繼續回到Nagios的架構。從下面的圖開始。

1. Nagios 架構總攬

從上到下，Nagios架構的幾個組成部件：

Web Interface: Nagios的Web頁面，Nagios的Web容器是Apache HTTPD，Nagios開發了一個HTTPD模組，並提供Web頁面。Web Interface與Nagios Daemon之間通過檔案介面互動，Web邏輯讀取Nagios的狀態檔案(status.dat)，展示其監控資訊。

Nagios Daemon: Nagios的主部件，實現了監控，效能，通知，事件處理功能。這些功能都是抽象的邏輯和排程，並沒有實際的與裝置互動的監控實現，與裝置的互動都是在下面一層的Plugin種實現的，這些就是Nagios認為可變部分。

Plugins: 各種與裝置互動獲取狀態或效能資料的實現。Nagios目前有2千多個外掛。Nagios通過定義外掛的抽象規範，將監控邏輯與實現隔離，也就是變與不變隔離。

Notification Commands: 通知命令。Nagios的Notification也是抽象的，具體的通知實現由Notification Commands實現，Notification Commands可以是一個簡訊貓，郵件客戶端等，負責以各種形式將狀態通知到外部。

Event Handlers: 事件處理的存在也是變與不變的博弈結果。Nagios允許使用者通過事件處理機制來干預其監控排程和結果。比如Nagios給物件的狀態分了Hard, Soft兩種型別，Soft狀態型別表示一箇中間狀態，不是最終狀態，每次狀態變化，Nagios都會回撥二次開發者註冊的事件處理函式，二次開發者在事件處理函式種判斷如果是Soft狀態型別，可以嘗試自動修復物件的狀態。

Performance Processors: 效能處理也是變與不變的結果（這是我最後一次說變與不變，不用再忍耐了：—)）。Nagios允許外掛輸出效能資料，並會將效能資料儲存到效能檔案種。但是Nagios自身理解不了外掛輸出的效能資料，因此，提供 Performance Processor 讓開發者定義效能處理函式。

圖中最下面一層是Nagios的物件，下面我們就開始介紹Nagios的物件模型。

2. Nagios Objects

Nagios的模型很簡單，因為簡單才接近真理，只有真理才是不變的，不變就是Nagios的設計目標。是不是很無厘頭？

Nagios的物件有：

• Host & Host Group & Host Dependency
  

  Host是一個監控世界裡的物理物件。如一臺主機，一臺乙太網交換機等，都是Host。 Host之間可以通過use關鍵字繼承屬性。避免重複屬性定義。
  Host Dependency 是Host之間的依賴，與組網相關。

• Service & Service Group & Service Dependency
  

  Service 是屬於Host的服務，比如POP3，HTTPD，自己開發的服務等，都可以定義為Service。 Service Dependency 用來定義Service之間的依賴，假設你將作業系統的0號程序定義為一個Service，那麼所有的其他Service都依賴此Service。

• Contact & Contact Group
  

  聯絡人。通知使用的。聯絡人可以定義Command的屬性，用來實現具體的通知。

• Time Period
  

  時間週期。方便監控世界裡描述時間而預定義一些時間段。比如三月的每個週日 12:00，停機。其中三月的每個週日 12:00就是一個時間週期。

• Command
  

  上面的所有物件都是抽象的，與監控裝置無關的。只有Command是需要與具體的監控裝置互動的。Command可以屬於Service或Host。Command的存在是為了使得Service和Host可以抽象定義。比如 Ping 就是一個Command，可以被繫結到所有的Host上，用於檢測Host的連通性，而不用每個Host實現一個Ping。

3. 巨集

抽象是有代價的。

抽象程度越高，資訊量越大，不確定性越多。

上面的Ping Command例子，當此Command被繫結到了多個Host，那麼執行時，次Command如何得知，該Ping哪個IP地址？

Nagios通過巨集解決這個問題：

Ping -c 8 -H $HOSTADDRESS ...

上面的 $HOSTADDRESS 就是一個巨集，代表 Command 在執行時所屬的Host的IP地址。Nagios在執行此Command的之前，會預編譯，將巨集替換為實際的值。

使用者可以自定義巨集，如何定義後續介紹。

4. 物件狀態定義

上面列出的Nagios物件，只有Host和Service是監控實體物件，有狀態。其他物件都是輔助監控而存在的。

Host狀態定義為：UP, DOWN, UNREACHABLE

Service 狀態定義為：OK, WARNING, UNKNOWN, CRITICAL

5. 外掛定義規則

Nagios的外掛與語言無關，只要是一個可執行檔案即可，並同時滿足下面兩個條件即可。

• 返回值
  

  外掛的返回值可以是：0，1，2，3，其意義分別為：OK，WARNING，CRITICAL，UNKNOWN。

Nagios依據外掛的返回值判定物件的狀態，外掛返回值與物件狀態之間的關係為：

外掛返回值Host 狀態Service 狀態

關於第二行第二列的值後續解釋。

• 螢幕輸出

  螢幕輸出的格式為：


TEXT OUTPUT | OPTIONAL PERFDATA

LONG TEXT LINE 1

LONG TEXT LINE 2

...

LONG TEXT LINE N | PERFDATA LINE 2

PERFDATA LINE 3

...

PERFDATA LINE N

上面的輸出描述為：


描述資訊 | 效能資料

長文字描述資訊1

長文字描述資訊2

...

長文字描述資訊N | 效能資料

效能資料

...

效能資料

Nagios會將這些資料都儲存到檔案種。

說實話，這種格式確實不好用。