0x05 Nagios Host Check

Nagios Host Check

目錄

• Nagios Host Check
  • 何時執行Check
  • 緩存host checks
  • Dependencies and checks
  • 主機的併發checks
  • 主機的狀態
  • 主機狀態變化
  • Predictive Host Dependecy Check
    • 預測性檢測工做原理

本篇主要講述主機監控的工做原理

何時執行Check

Check的調度配置是經過Nagios Core Deamon控制

1. 按期性檢測，由主機定義中的check_interval和retry_interval選項
2. 按需，當一個與主機關聯的服務狀態發生變化時
3. 按需，做爲主機可達邏輯的一部分，會進行check觸發
4. 按需，做爲predictive dependency checks的一部分，會觸發check.

按期性檢查：若是設置check_interval is zero 那麼就不會進行按期檢查。
關聯服務觸發的檢查：該檢查被觸發，當一個主機關聯的服務改變了狀態，由於Nagios Core 須要知道是否主機已經在服務狀態改變以前已經改變了狀態。這個很好理解，由於一般一個服務狀態發生了變化，咱們很大基礎上會去想知道，承載服務的基礎，host是否狀態已經發生變化。
做爲主機可到邏輯的一部分所觸發的主機檢查：Nagios Core被設計用於儘量快的發現網絡斷電，區分Down和Unreachable兩種狀態。這是很是不一樣的兩種狀態，能夠幫助管理員快速定位形成網絡斷電的位置。這是一種parent/child關係，咱們要保證這種邏輯鏈的健康，好比說網絡ip可達，來檢測這種鏈路是健康的。不過一旦不可達了，那麼就須要快速定位是鏈路中哪一個或者哪些節點出了問題。一般咱們會從哪裏開始入手呢？這就是從nagios做爲網絡的根節點，而後依次是nagios經過網絡設備達到各個host，固然網路設備也是host。以下圖，能夠從nagios爲root來構建的一個樹結構:

當其中一個或者幾個主機狀態發生變化，那麼邏輯可達中的全部主機將進行一個併發的check，當收到每一個節點的check結果後，nagios會斷定這個節點的check路徑上的上峯節點的check狀態是否有不正常的，若是有，那麼該節點狀態爲Unreachable而不是down，若是上峯節點都是正常的，那麼該節點狀態就是Down，由於上峯不可達後，那麼依賴上峯的當前節點狀態是未知的，上峯節點阻塞了檢查，那麼就該斷定爲Unreachable。
固然對於down和unreachable狀態監控仍是都會通知到相關contact的。而後admin會根據網絡拓撲圖，從nagios角度出發，來發現down的設備。

做爲predictive host dependecy check 邏輯的一部分被觸發：
可預測的依賴檢查，單獨放在後面的Predictive Host Dependecy Check講。

緩存host checks

經過實現緩存檢查的使用，能夠顯着提升按需主機檢查的性能，這使Nagios Core能夠在肯定相對較新的檢查結果的狀況下放棄執行主機檢查。有關緩存檢查的更多信息，請參見此處。
也就是說，常規計劃性的檢查結果緩存下來，可用於突發的按需檢查，避免了屢次價差請求，已提升性能。

Dependencies and checks

您能夠定義主機執行依賴性，以防止Nagios Core根據一個或多個其餘主機的狀態來發起一個檢查當前主機的狀態。這個屬於高階知識點，有關依賴關係的更多信息，請參見此處。

主機的併發checks

計劃的主機檢查是並行運行的。當Nagios Core須要運行計劃的主機檢查時，它將啓動主機檢查，而後返回執行其餘工做（運行服務檢查等）。主機檢查在從主要Nagios Core守護程序進行fork（）處理的子進程中運行。主機檢查完成後，子進程將把檢查結果通知主Nagios Core進程（其父進程）。而後，主要的Nagios Core流程將處理檢查結果並採起適當的措施（運行事件處理程序，發送通知等）。

若是須要，還能夠並行運行按需主機檢查。如前所述，Nagios Core若是可使用相對較新的主機檢查中的緩存結果，則能夠放棄按需主機檢查的實際執行。

當Nagios Core處理計劃的和按需的主機檢查結果時，它可能會啓動（輔助）其餘主機的檢查。能夠出於兩個緣由啓動這些檢查：預測依賴性檢查和使用網絡可達性邏輯肯定主機的狀態。啓動的輔助檢查一般並行運行。可是，您應該意識到一個大例外，由於它可能會對性能產生負面影響...

將max_check_attempts值設置爲1的主機可能會致使嚴重的性能問題。緣由？若是Nagios Core須要使用網絡可達性邏輯來肯定其真實狀態（以查看它們是DOWN仍是UNREACHABLE），則它將必須啓動對主機的全部直接父級的串行檢查。重申一下，這些檢查是串行運行的，而不是並行運行的，所以可能會嚴重影響性能。所以，我建議您始終在主機定義中爲max_check_attempts指令使用大於1的值。

主機的狀態

• UP
• DOWN
• UNREACHABLE

主機狀態變化

如您所知，主機並不是老是保持一種狀態。 事情中斷了，補丁被應用了，服務器須要重啓。 當Nagios Core檢查主機狀態時，它將可以檢測到主機什麼時候在UP，DOWN和UNREACHABLE狀態之間切換，並採起適當的措施。 這些狀態更改致使不一樣的狀態類型（HARD或SOFT），這能夠觸發事件處理程序的運行和通知的發送。 檢測並處理狀態更改是Nagios Core的所有目的。

當主機更改狀態的頻率過高時，它們被視爲「拍動」。 主機波動的一個很好的例子是服務器，一旦操做系統加載，該服務器就會自發重啓。 這老是頗有趣的狀況。 Nagios能夠檢測主機什麼時候開始震盪，而且能夠抑制通知，直到震盪中止而且主機的狀態穩定爲止。 能夠在此處找到有關襟翼檢測邏輯的更多信息。

Predictive Host Dependecy Check

預測依賴性檢測

主機和服務的依賴能夠被定義來容許你更好的控制，何時checks被執行和何時通知被髮送。因爲依賴關係用於控制監視過程的基本方面，所以相當重要的是，確保依賴關係邏輯中使用的狀態信息儘量最新。

Nagios Core 容許你進行預測性的依賴檢測，針對hosts和service用於去肯定依賴邏輯有最新新的狀態信息，當咱們須要這些信息去肯定是否發送通知或容許觸發一次主機或服務檢測。

預測性檢測工做原理

白話說就是，當檢測到一個主機或者服務有問題時。會去預測性的發出它說依賴的依賴服務主機和有直接網絡邏輯的父和子的進行一次check。

下圖顯示了Nagios Core監視的主機的基本示意圖，以及它們的父/子關係和依賴關係。

在此示例中，Switch2主機剛剛將狀態從UP狀態更改成問題狀態。 Nagios Core須要肯定主機是DOWN仍是UNREACHABLE，所以它將啓動對Switch2的直接父代（Firewall1）和子代（Comp1，Comp2和Switch3）的並行檢查。這是主機可達性邏輯的正常功能。

您還將注意到，Switch2依賴於Monitor1和File1來進行通知或檢查執行（在此示例中，哪一個不重要）。若是啓用了預測性主機依賴性檢查，則Nagios Core將同時啓動Monitor1和File1的並行檢查，並啓動Switch2的直系父母和孩子的檢查。 Nagios Core之因此這樣作是由於它知道在不久的未來（例如出於通知目的）必須測試依賴關係邏輯，而且它想確保它具備參與依賴關係的主機的最新狀態信息。