OpenNMS全接觸-事件及通知（十一）

 作為網管軟體，當網絡中一些重要情況發生時，及時準确的通知使用者是最基本的功能之一，OpenNMS自然也不例外。實作一個基本的通知功能，需要解決以下三個基本問題：通知給誰，如何通知，通知的内容。這三部分對應于OpenNMS中的三個配置檔案：

• destinationPaths.xml，該檔案定義了通知發送的對象
• notificationCommands.xml，該檔案定義了如何發送通知
• notifications.xml，該檔案定義了通知的内容

下面我們就通過介紹這三個檔案來詳細介紹OpenNMS的通知機制。

在這之前，OpenNMS中還有一個與通知有關的配置檔案，notifd-configuration.xml檔案。在該檔案中定義了與通知服務相關的一些參數，如通知隊列的一些參數，包括隊列ID，時間間隔，及處理類等。另外還定義了自動确認通知，這種自動确認通知的意義在于，當給使用者發出某個接口down掉或者某個服務不可用後，如果接口又UP起來或者服務又恢複了，則可以自動發送通知給使用者高速使用者故障已恢複。這種自動确認通知非常有必要，因為按照一般的故障模型，當一個故障持續的時間越長，則其重要性及優先級則不斷提高，而這種自動确認通知則阻止了故障因為持續時間不斷變長而不斷提高其優先級。那麼OpenNMS又是如何判斷出什麼時候該自動發這種通知呢？對于自動而言，顯然發送的時間非常重要，既不能提前，那是誤報，又不能滞後，那樣就沒有實際意義了。首先我們可以這樣了解，當一個故障發生，會産生相應的事件，而該事件則會導緻某個通知發出，那麼當該故障恢複後，則對應有另外一個事件發生，那麼當該事件發生時，OpenNMS就自動發送故障恢複的通知了。是以在這裡有兩個對應的事件，一個在故障發生時産生，另外一個則在故障恢複是産生，正是這個恢複事件導緻自動确認通知的發出。先在notifd-configuration.xml檔案中定義了五對這樣的事件。它們分别是：

serviceUnresponsive->serviceResponsive

nodeLostService->nodeRegainedService

interfaceDown->interfaceUp

nodeDown->nodeUp

wideSpreadOutage->wideSpreadOutageResolved

那麼對于這五對事件，為了能夠比對它們，又給它們定義了比對規則，例如對于serviceUnresponsive和serviceResponsive事件，要比對它們的nodeid，interfaceid及serviceid。

下面我們介紹下其他三個配置檔案，首先看下destinationPaths.xml檔案：