Passive nodes are nodes that Horizon 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 Horizon cannot actively poll them and instead passively relies on information sent from somewhere else.
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 Horizon 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.
The PassiveStatusKeeper updates its hash table when a
uei.opennms.org/services/passiveServiceStatus is processed.
The event must include the following parameters:
Must be exactly the same as the node name in Horizon and is case sensitive.
The IP interface of the node with a PassiveStatusMonitor service
The name of the PassiveStatusMonitor service
Must be either
Downand is case sensitive.
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
If you will have only one service to monitor passively, set a basic service in
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
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
<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" />