Feature Description

Starting with NMIS 8.6.2a user-defined polling policies are supported, which allows particular nodes to be polled more or less frequently than the normal 5-minute default.

Administrators can define the following attributes when configuring a polling policy:

The GUI presents a variety of time choices for these attributes, ranging from 1 minute (which is the minimum supported by NMIS) to 1 day; other selections can be added by editing 

conf/Table-Polling-Policy.nmis, fractional frequency settings (3.5m or 1.5h) are supported.

Each policy must be given a unique name, which cannot be changed after creation.

The policy named "default" is special: any node that is not assigned a particular polling policy is subject to this "default" policy. The "default" policy is always available and contains the standard 5-minute frequency unless explicitly overridden.

To change a node's polling frequencies from the defaults supplied, the node must be assigned a polling policy in its configuration.

Hardcoded model sections (e.g. hrsmpcpu) are controlled by the policy's SNMP frequency.

Increasing the ICMP/Ping frequency will not cause the reachability statistics to be updated more frequently.  Increasing the ICMP/Ping frequency will provide more granular node up/down alerts.

For nodes that are polled with SNMP and WMI concurrently, the shorter of the two polling frequencies will control overall polling of the node, but data collection with each source type will be attempted based on its frequency settings. This can lead to visually confusing results. It's not recommended to create policies with different timings for SNMP and WMI.

Service Polling

Polling for Service monitoring has supported variable frequencies for quite some time, and is configured independently from nodes: when defining the service parameters in Services.nmis, you can set the service polling frequency for that particular service.

Defaults

Polling Interval Defaults, If no policy is assigned or the automatic "default" policy is used:

Limitations and Caveats

When and how are Polling Policies evaluated?

A polling policy has two effects:

  1. it controls the candidate selection for collect and ping,
  2. and it defines critical parameters for the RRD files that store the collected information.

Candidate selection

Whenever an NMIS collect cycle starts, only the nodes whose last poll was earlier than their SNMP/WMI collect frequency are chosen.
(NMIS's nmis.pl starts once every minute, so the interval granularity is 60s. If your policy indicates a frequency of 1.5m (= 90 seconds), then NMIS will poll this node at time T, T+2m, T+4m and so on.)

For PING/ICMP, the NMIS fpingd component runs always and will try to ping nodes as close as possible with their configured ping frequency.

RRD parameter setting

Polling policies are also evaluated when a new RRD file is created, because the expected frequency of new data to enter the storage is vital knowledge for the RRD subsystem's functioning.
However, these RRD parameters cannot be modified for an existing RRD file - they can only be given on creation.

Changing the later would have no effect for existing  RRD files, and Polling policies can therefore not be modified after having been created.

Changing a node's polling policy discards all of the node's data

The  timing parameters cannot be changed for existing RRD files, and it is not feasible to retroactively rework the data in an existing RRD file, therefore switching policies implies a complete loss of all of the node's historic data.

When you switch a node to a different polling policy, all its existing RRD files are deleted and new RRD files are created that reflect the new polling policy.

(The RRD file deletion does not happen instantly: assuming your node is named X, its  rrd directory database/nodes/X is renamed to X.policy-<oldpolicy>-<timestamp>, which will then be deleted eventually. To back out of an inadvertent policy change you could remove the new node directory and rename the backup one, after having reset the polling policy associated with the node).

Configuration

Configure a Polling Policy

From the NMIS8 home dashboard using the top menu bar navigate to Setup -> Polling Policy.  This will render the 'Polling Policy'  overview window.  From this window polling policies may be added, viewed and deleted.   

Click the 'add' link and a new window will render.

In this window enter a 'Policy Name', select the polling frequencies, and optionally add a Description.  When finished click the 'Add' button.

Assign the Polling Policy

Polling Policy assignment is done via the Edit Node window.  From the NMIS8 top menu bar navigate to System -> System Configuration -> NMIS Nodes (Devices).  'Table Nodes' will render.  Click the 'edit' link for a node.  The node edit window will render.  In the 'Advanced Options' section look for the 'Polling Policy' attribute.

From the 'Polling Policy' drop down menu, the currently configured polling policies will be available for assignment. Once finished, click the 'Edit and Update Node' button at the bottom of the Edit Node window.

Please note that a polling policy can be deleted only if no nodes are associated with it.

Verification

This is an optional step, use this if you need to show and see the verification that the activities are happening with higher or lower frequency.  The easiest way is to zoom into one of the graphs for the node, then click on the "Stats" link in the quick access link bar: The column "step" should reflect your polling policy's frequency in seconds. For the default policy, you'll see a step of 300 (seconds or 5 minutes). Please note that you will see the true "step" value only if you zoom into the graph.

SNMP/WMI

In order to verify that the polling interval is occurring at the dictated frequency, you can request status information from rrdtool.  Likely candidate rrd files for each type of polling are listed below.

Run an rrdtool info request such as the one below that demonstrates checking the SNMP polling interval.

[chrisg@thor interface]$ rrdtool info fastethernet0-0.rrd | head
filename = "nmis8/database/nodes/somenode/interface/fastethernet0-0.rrd"
rrd_version = "0003"
step = 120

The "step" value represents the polling frequency in seconds, in the example above it's a 2-minute polling policy.

ICMP/Ping

In order to verify the ICMP/Ping polling frequency the simplest way is to restart fpingd with logging enabled and observe its log in logs/fpingd.log:

[root@opmantek conf]# sudo /usr/local/nmis8/bin/fpingd.pl logging=true restart=true
[root@opmantek conf]# grep gc-r1 logs/fpingd.log
...
24-Aug-2017 11:59:48 fpingd.pl[21445] gc-r1 is pingable: returned min/avg/max = 0.65/0.67/0.72ms loss=0%
24-Aug-2017 12:00:18 fpingd.pl[21445] gc-r1 is pingable: returned min/avg/max = 0.64/0.68/0.74ms loss=0%
24-Aug-2017 12:00:49 fpingd.pl[21445] gc-r1 is pingable: returned min/avg/max = 0.64/0.69/0.76ms loss=0%
24-Aug-2017 12:01:19 fpingd.pl[21445] gc-r1 is pingable: returned min/avg/max = 0.7/0.75/0.83ms loss=0%
...
[root@opmantek conf]# sudo /usr/local/nmis8/bin/fpingd.pl restart=true

In the example above you' see that node gc-r1 is subject to a 0.5m (or 30 second) ping polling policy.

You can also observe these policy values when viewing the var/nmis-fping.json data file, which shows the ping frequencies in the lastping and nextping attributes of each node.

Please note that fpingd logging creates substantial amounts of log data, and it's recommended that you run your fpingd without logging when not needed for diagnostic efforts.