作爲網管軟件，當網絡中一些重要情況發生時，及時準確的通知用戶是最基本的功能之一，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文件：
destination path，我們暫且翻譯其爲通知路徑吧，其實它定義了不止通知路徑了，它實際上定義了誰、什麼時間以及如何收到通知。我們看下一個path的構成元素吧：
一個通知路徑由一個或者多個通知目標組成，另外還可以定義通知升級。對於每個通知目標，它又包括了一個名稱、一個或者多個通知命令（如email通知，頁面通知等），還可以定義是否自動通知，另外通知目標還有個屬性interval，它定義了通知發送的週期。另外對於通知目標而言，還有個比較重要的屬性，即自動通知屬性，可以設置爲on或者off。對於自動通知屬性的作用，將在下一篇文章中繼續介紹。