作为网管软件，当网络中一些重要情况发生时，及时准确的通知用户是最基本的功能之一，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。对于自动通知属性的作用，将在下一篇文章中继续介绍。