PassiveStatusMonitor
Passive nodes are nodes that Meridian is unable to directly communicate with because either they are 'not real' or because there is no network path directly to the device. They are termed 'Passive' because Meridian cannot actively poll them and instead passively relies on information sent from somewhere else.
PassiveStatusKeeper
The PassiveStatusKeeper maintains the status of passive services in memory with a hash table. The PassiveStatusMonitor is called by pollerd, just as the other IP-based monitors. However, its behavior is to report the status currently represented in the PassiveStatusKeeper’s hash table. No polling on the network is performed. This hash table will either contain the latest status reported by a passive status event, or, if no status messages have been received, the PassiveStatusKeeper defaults to status "Up".
During Meridian initialization, the outages database table is queried to set the initial state of any passive service based on the last-known outage condition when services previously stopped.
Passive Status Events
The PassiveStatusKeeper updates its hash table when a uei.opennms.org/services/passiveServiceStatus is processed.
The event must include the following parameters:
- passiveNodeLabel
-
Must be exactly the same as the node name in Meridian and is case sensitive.
- passiveIpAddr
-
The IP interface of the node with a PassiveStatusMonitor service
- passiveServiceName
-
The name of the PassiveStatusMonitor service
- passiveStatus
-
Must be either
UporDownand is case sensitive. - passiveReasonCode
-
Optional field, typically only present in down events, that can be used to enrich the event with specific information regarding the reason for the service down event.
Any event with this specific UEI and parameter set triggers a PassiveStatusKeeper update.
If sending events directly from an external system such as via REST or Kafka Consumer, the event can be sent directly with these parameters for Eventd to process.
If you will be extracting passive status updates from traps or syslog messages, you can use the event translator to generate the uei.opennms.org/services/passiveServiceStatus events.
Examples
If you will have only one service to monitor passively, set a basic service in ${OPENNMS_HOME}/etc/pollerd-configuration.xml.
Note that you must include the monitor section for each service in your definition.
<service name="PassiveStatus" interval="60000" user-defined="true" status="on">(1)
</service>
<monitor service="PassiveStatus" class-name="org.opennms.netmgt.poller.monitors.PassiveServiceMonitor" />| 1 | As the monitor checks the PassiveStatusKeeper table in memory, small interval times allow for quick responses to updates with minimal overhead.
Interval times of 30 seconds to 60 seconds (as used in this example) are typical for this type of monitor. |
If you will have multiple passive monitors on a node, using service patterns can make configuration easy.
With the following example, any service added to a node that matches the wildcard Passive-* will match a PassiveStatusKeeper update event for the corresponding passiveServiceName parameter.
<service name="Passive-" interval="60000" user-defined="true" status="on">
<pattern><![CDATA[^Passive-(?<name>.*)$]]></pattern>
</service>
<monitor service="Passive-" class-name="org.opennms.netmgt.poller.monitors.PassiveServiceMonitor" />