為服務的不同檢查級別配置 Nagios event_handler 而不重疊

執行 Nagios Core 4.0.2 並在客戶端上使用最新的 NRPE。

我們有 3 個服務定義來每分鐘檢查一個不同級別的軟體：

1. 打開 TCP 埠檢查
2. 程序正在執行檢查
3. 通過向套接字發送數據並期望一些返回值來檢查應用層

在任何這些檢查的失敗狀態下，我們將呼叫 event_handler 來重新啟動服務最多 3 次。如果 3 後狀態不正常，則升級。

問題是有許多組合，如果一項服務失敗，另一項服務預計將處於 CRITICAL 狀態。如果我們每個都有一個 event_handler 並且兩個失敗，那麼通過 event_handler 的重啟腳本將被呼叫兩次。

1. 例如，如果程序沒有執行，那麼 TCP 埠將不會打開，應用層檢查將失敗。
2. 例如，由於防火牆錯誤配置的規則或網路條件，TCP 埠可能是 CRITICAL，並且應用層將失敗，因為它無法到達但程序仍在執行

**問題：**我們如何確保事件處理程序僅被一個失敗的服務檢查呼叫，而不是為 3 個失敗的服務呼叫，導致 2 次或更多次重新啟動，因為它們的狀態變為 CRITICAL？例如，如果 3 次服務檢查進入 CRITICAL，那麼這將是 3 次在 1 分鐘內重新啟動，6 次在 2 分鐘內重新啟動（假設重新啟動未能使服務恢復到 OK 狀態）。

我相信服務依賴可能是正確的解決方案，但我不確定如何創建它們以滿足不同的條件。

服務依賴是實現它的方法。

你想讓你的應用層服務檢查依賴於你的程序執行檢查。

你想讓你的程序執行檢查依賴於你的 TCP 埠檢查。

您想讓所有這些都依賴於主機（而不是服務）檢查 - 這解決了“網路條件”故障場景。

這些可能會很快變得非常複雜，但基本思想是：

define servicedependency{
host_name                      TheServer
service_description            The Service I Depend On
dependent_host_name            TheServer
dependent_service_description  The Dependent Service
execution_failure_criteria     n
notification_failure_criteria  w,u,c

}

execution_failure_criteria 確實是這裡的主力：它列出了主服務可以在此服務不被檢查的狀態（在這種情況下，如果服務“我依賴的服務”處於“通知”狀態。您可以指定多個選項（如下行所示）。

這是對 nagios 配置選項的一個很好的解釋。 http://nagios.frank4dd.com/docs/en/objectdefinitions.html#servicedependency

引用自：https://serverfault.com/questions/576891