通知事項

介紹

關于通知的確切工作方式存在很多問題。這將試圖解釋發送主機和服務通知的時間和方式，以及誰接收它們。

通知升級將在此處進行說明。

通知何時發生？

發出通知的決定是在服務檢查和主機檢查邏輯中做出的。僅在處理與該通知相對應的主機或服務檢查時才觸發是否要發送通知的計算。它們不僅僅因為自從發送上一個通知以來已經過去了而被觸發。主機和服務通知在以下情況下發生：

• 當硬狀態發生變化時。有關狀態類型和硬狀態更改的更多信息，請參見此處。

• 當主機或服務保持硬非OK狀態并且自上次發出通知以來（針對該指定的主機或服務），主機或服務定義中的< notification_interval >選項指定的時間已經過去。

如果主機處于硬非正常狀態，則不會發送該主機上的服務通知。

誰得到通知？

每個主機和服務定義都有一個< contact_groups >選項，該選項指定哪些聯系人組接收該特定主機或服務的通知。聯系人組可以包含一個或多個單獨的聯系人。

當Nagios Core發送主機或服務通知時，它將通知服務定義的< contactgroups >選項中指定的任何聯系人組成員的每個聯系人。Nagios Core意識到一個聯系人可能是多個聯系人組的成員，因此它在執行任何操作之前會刪除重復的聯系人通知。

為了發送通知，必須通過哪些過濾器？

僅僅因為需要發送主機或服務通知并不意味著任何聯系人都會得到通知。在潛在通知被認為足夠值得發送之前，必須通過幾個過濾器。即使那樣，如果特定聯系人的通知過濾器不允許將通知發送給他們，則可能不會被通知。讓我們進入必須更詳細地傳遞的過濾器。

• 程序范圍過濾器：

  通知必須通過的第一個過濾器是測試是否在程序范圍內啟用通知。最初由主配置文件中的enable_notifications指令確定，但在運行時可以通過Web界面進行更改。如果在整個程序范圍內都禁用了通知，則無法發送主機或服務通知。如果在程序范圍內啟用了它們，則還必須通過其他測試。

• 服務和主機過濾器：

  主機或服務通知的第一個過濾器是檢查主機或服務是否處于計劃的停機時間內。如果在計劃的停機時間內，則不會有人收到通知。如果不在停機時間，它將繼續傳遞到下一個過濾器。附帶說明一下，如果與服務相關聯的主機處于計劃的停機時間范圍內，則會取消服務通知。

  主機或服務通知的第二個過濾器是檢查主機或服務是否正在抖動（如果啟用了抖動檢測）。如果服務或主機當前正在震蕩，則不會有人收到通知。否則，它將被傳遞到下一個過濾器。

  必須傳遞的第三個主機或服務過濾器是特定于主機或服務的通知選項。每個服務定義都包含一些選項，這些選項確定是否可以針對警告狀態，嚴重狀態和恢復發送通知。同樣，每個主機定義都包含一些選項，這些選項確定當主機發生故障，變得無法訪問或恢復時是否可以發送通知。如果主機或服務通知未通過這些選項，則不會通知任何人。如果確實通過這些選項，則通知將傳遞到下一個過濾器。注意：僅當針對原始問題發出通知時，才發送有關主機或服務恢復的通知。收到您從未知道的問題的恢復通知是沒有意義的。

  必須通過的第四個主機或服務過濾器是時間段測試。每個主機和服務定義都有一個< notification_period >選項，該選項指定哪個時間段包含主機或服務的有效通知時間。如果發出通知的時間不在指定時間段內的有效時間范圍內，則不會有人聯系。如果它在有效時間范圍內，則通知將傳遞到下一個過濾器。注意：如果未通過時間段過濾器，Nagios Core將為主機或服務的下一個通知（如果其處于非OK狀態）重新安排該時間段中存在的下一個有效時間。這有助于確保在下一個有效時間段到達時盡快將問題通知給聯系人。

  最后一組主機或服務過濾器取決于兩件事：（1）過去某個時候已經發出有關主機或服務問題的通知，并且（2）主機或服務保持在同一狀態非正常狀態，即上次通知發出的時間。如果滿足這兩個條件，則Nagios Core將檢查并確保自上次通知發出以來經過的時間達到或超過主機或服務定義中的< notification_interval >選項指定的值。如果自上次通知以來沒有足夠的時間，則沒有人聯系。如果自上次通知以來已經過了足夠的時間，或者不滿足此過濾器的兩個條件，則將發出通知！它是否實際發送給各個聯系人取決于另一組過濾器。

• 聯系人過濾器：

  此時，通知已通過程序模式過濾器和所有主機或服務過濾器，Nagios Core開始通知所有人員。這是否意味著每個聯系人都將收到通知？否。每個聯系人都有自己的一組過濾器，在收到通知之前，必須通過該過濾器。注意：聯系人過濾器特定于每個聯系人，并且不影響其他聯系人是否接收通知。

  通知選項是必須為每個聯系人傳遞的第一個過濾器。每個聯系人定義均包含用于確定是否可以針對警告狀態，嚴重狀態和恢復發送服務通知的選項。每個聯系人定義還包含一些選項，這些選項確定在主機發生故障，無法訪問或恢復時是否可以發送主機通知。如果主機或服務通知未通過這些選項，則不會通知該聯系人。如果確實通過這些選項，則通知將傳遞到下一個過濾器。注意：僅當針對原始問題發出通知時，才發送有關主機或服務恢復的通知。收到您從未知道的問題的恢復通知是沒有意義的。

  每個聯系人必須通過的第二個過濾器是主機或服務重要性過濾器。對于服務檢查，如果服務的重要性值小于聯系人的minimum_importance值，則不會通知該聯系人。對于主機檢查，如果主機的重要性值加上主機上所有服務的重要性值小于聯系人的minimum_importance值，則不會通知該聯系人。否則，聯系人將通過主機/服務值過濾器，并且通知將傳遞到下一個過濾器。注意：如果不使用重要性值和minimum_importance值，則它們的值默認為零。在這種情況下，聯系人的minimum_importance值等于（但不小于）主機/服務重要性值，并且通知將傳遞到下一個過濾器。

  每個聯系人必須通過的最后一個篩選器是時間段測試。每個聯系人定義都有一個< notification_period >選項，該選項指定哪個時間段包含該聯系人的有效通知時間。如果發出通知的時間不在指定時間段內的有效時間范圍內，則不會通知該聯系人。如果它在有效時間范圍內，則會通知該聯系人！

通知方式

您可以讓Nagios Core隨時以任何想要的方式通知您問題和恢復：傳呼機，手機，電子郵件，即時消息，音頻警報，觸電等。通知的發送方式取決于對象定義中定義的通知命令文件。

注意：如果根據快速入門指南安裝Nagios Core ，則應將其配置為發送電子郵件通知。您可以通過查看以下文件的內容來查看使用的電子郵件通知命令：/usr/local/nagios/etc/objects/commands.cfg。

特定的通知方法（分頁等）不會直接合并到Nagios Core代碼中，因為這沒有多大意義。Nagios Core的“核心”并非旨在成為多合一應用程序。如果將服務檢查嵌入在Nagios Core中，那么用戶將很難添加新的檢查方法，修改現有檢查等。通知的工作方式與此類似。有上千種通知方法，并且已經有很多處理臟活的包裹，那么為什么要重新發明輪子并將自己局限于自行車輪胎呢？讓外部實體（例如，簡單的腳本或功能完善的消息傳遞系統）做些雜亂的事情要容易得多。

通知類型宏

在編寫通知命令時，您需要考慮正在發生的通知類型。在$ NOTIFICATIONTYPE $宏包含一個字符串，標識這一點。下表列出了該宏的可能值及其各自的描述：

有用的資源

您可以通過多種方式將Nagios Core配置為發送通知。由您決定要使用哪種方法。完成后，您必須先安裝任何必要的軟件并在配置文件中配置通知命令，然后才能使用它們。以下是一些可能的通知方法：

• 電子郵件

• 傳呼機

• 電話（SMS）

• WinPopup消息

• Yahoo，ICQ或MSN即時消息

• 聲音警報

基本上，您可以從命令行執行的任何操作都可以定制為用作通知命令。

如果您正在尋找使用電子郵件發送消息到尋呼機或手機的替代方法，請查看這些軟件包。它們可以與Nagios Core結合使用，以在出現問題時通過調制解調器發送通知。這樣，您不必依靠電子郵件來發送通知（請記住，如果存在網絡問題，電子郵件可能不*起作用）。我實際上沒有親自嘗試過這些軟件包，但是其他人已經報告使用它們成功。

• Gnokii（用于通過GSM網絡與諾基亞電話聯系的SMS軟件）

• QuickPage（字母數字尋呼機軟件）

• Sendpage（分頁軟件）

如果您想嘗試一種非傳統的通知方法，則可能需要弄亂音頻警報。如果要在監視服務器上播放音頻警報（帶有合成語音），請查看Festival。如果您不愿意將監視框放在一邊，而在另一個監視框上播放音頻警報，請查看網絡音頻系統（NAS）和rplay項目。