From OpenNMS
Many events that represent an outage of some sort also have a matching "clearing" outage which is sent when the original problem is resolved. An example is a "nodeDown" event and a matching "nodeUp" event. OpenNMS has the idea of an acknowledging event that will auto-acknowledge the original event. (See Configuring notifications.)
Just like a normal acknowledgment, an automatic acknowledgment will stop the destination path from being walked for the original notification. It will also create a new notification to tell users that the original issue is resolved. By default, a RESOLVED notification will occur whenever a "down" notification occurred and an automatic acknowledgement occurs. If an opennms user manually acknowledges a notification before an automatic acknowledgement occurs, then no RESOLVED notice is sent.
The <autoNotify> tag can be used in destinationPaths.xml to modify this default behavior. It gives the opennms administrator much greater flexibility in meeting users requirements for notifications for down/up event pairs. The <autoNotify> tag acts within a <target> and can be applied to each <target> as needed.
In the following example, the RESOLVED message will always be sent for this <target>, regardless of whether or not an opennms user acknowledged the original notification.
<target>
<name xmlns="">mail-admin</name>
<autoNotify xmlns="">on</autoNotify>
<command xmlns="">email</command>
</target>
This can be used to simplify the "up" notification process. By always sending the RESOLVED message, the "up" notification becomes redundant and is no longer necessary.
In the second example, the RESOLVED notification will never be sent for this <target>.
<target>
<name xmlns="">mail-admin</name>
<autoNotify xmlns="">off</autoNotify>
<command xmlns="">email</command>
</target>
This is useful for people who only want "down" notifications. It also can be used to avoid multiple RESOLVED messages going to the same users as a result of escalations that notify the same users multiple times.






