Ability to disable the scheduling for rescan existing nodes when Provisiond starts

Description

The poller/collector servers used on this environment are monitoring different sets of requisitioned nodes on different networks. There are firewalls that prevents each poller/collector server reaching the network monitored by other poller/collector server.

The idea is that each poller/collector server is responsible for the nodes that it is supposed to monitor.

The problem is that when Provisiond starts, it schedules the rescan of all existing nodes on the database. This sounds to be a good thing if we use a single OpenNMS instance. But in this particular environment this doesn't make sense because OpenNMS is going to try to scan all nodes defined on the database on all poller/collector servers.

This is an operation executed when Provisiond starts, so it will be wonderful to define a system property to disable this operation in order to avoid this kind of problems on distributed environments.

Environment

Distributed environment for OpenNMS, where there are: one shared PostgreSQL server shared, one shared repository for RRDs and multiple Poller/Collector servers.

Acceptance / Success Criteria

None

Lucidchart Diagrams

Activity

Show:

Jiri Tyr March 11, 2013 at 6:46 PM

Thanks for the explanation, Alejandro. I will try to schedule the rescan as you suggested.

Alejandro Galue March 11, 2013 at 2:34 PM

Jiri, after analyzing the code and doing some experiments, I can verify that scheduleRescanForExistingNode is doing what it is supposed to do; I mean, enable/disable the rescan for existing nodes.

That means, if this option is false, OpenNMS is not going to schedule a rescan neither at initialization time, nor at recurring intervals defined in "Scan Interval", for the nodes defined on your system.

Keep in mind that the current OpenNMS was not implemented for distributed environments like yours.

The current code of Provisiond is not prepared for a distributed OpenNMS, so in your case, you can deal with this situation doing the following:

1) Keep scheduleRescanForExistingNode=false (this is very important)
2) Create a schedule on provisiond-configuration.xml on each P/C for each requisition you want to update at recurring intervals, for example:

<requisition-def import-name="Local-MySampleGroupOfNodes" import-url-resource="file:///opt/opennms/etc/imports/MySampleGroupOfNodes.xml">

<cron-schedule>0 0 0 * * ? *</cron-schedule>
</requisition-def>
{xml}

I haven't tested the second part yet, but it should work.

Makes sense?

Alejandro Galue March 11, 2013 at 12:53 PM

When scheduleRescanForExistingNode is set to be false, the recurrent node scan is not being performed, and a manual workaround is used instead.

Alejandro Galue March 11, 2013 at 12:52 PM

Jiri,

Thanks for the details. I just wanted to make sure about your current settings before trying to reproduce the problem locally. I'm going to do that to see which part of the code is not being executed when scheduleRescanForExistingNodes is false.

Jiri Tyr March 11, 2013 at 12:47 PM

So far we do not have any per-provisioning group Foreign Source definition (directories etc/foreign-sources/ and etc/foreign-sources/pending/ are empty). Our default-foreign-source.xml looks like this (managed centrally by Puppet):

<foreign-source date-stamp="2012-10-31T12:37:35.614Z" name="default" xmlns="http://xmlns.opennms.org/xsd/config/foreign-source">
<scan-interval>1d</scan-interval>
<detectors>
<detector class="org.opennms.netmgt.provision.detector.icmp.IcmpDetector" name="ICMP"/>
<detector class="org.opennms.netmgt.provision.detector.snmp.SnmpDetector" name="SNMP"/>
</detectors>
<policies>
<policy class="org.opennms.netmgt.provision.persist.policies.MatchingIpInterfacePolicy" name="Persist only explicitly defined IPs">
<parameter value="DO_NOT_PERSIST" key="action"/>
<parameter value="NO_PARAMETERS" key="matchBehavior"/>
</policy>
</policies>
</foreign-source>

So it should rescan the device every day but it doesn't. I had to forceRescan several devices as described in my last comment in order to initiate the SNMP data collection.

Please let me know if you want me to do some more tests.

Configuration

Details

Assignee

Reporter

Labels

Components

Fix versions

Affects versions

Priority

PagerDuty

Created November 5, 2012 at 1:47 PM
Updated January 27, 2017 at 4:20 PM
Resolved March 11, 2013 at 2:34 PM