- Feature Description
- Limitations and Caveats
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:
- ICMP/Ping frequency
- SNMP Polling frequency
- WMI polling frequency
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 (
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.
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.
Polling Interval Defaults, If no policy is assigned or the automatic "default" policy is used:
- ICMP: 1 Minute
- SNMP: 5 Minutes
- WMI: 5 Minutes
Limitations and Caveats
When and how are Polling Policies evaluated?
A polling policy has two effects:
- it controls the candidate selection for collect and ping,
- and it defines critical parameters for the RRD files that store the collected information.
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).
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.
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.
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.
- SNMP - /usr/local/nmis8/database/nodes/<node name>/interface/<interface name>.rrd
- WMI - /usr/local/nmis8/database/nodes/<node name>/health/WindowsProcessor.rrd
Run an rrdtool info request such as the one below that demonstrates checking the SNMP polling interval.
The "step" value represents the polling frequency in seconds, in the example above it's a 2-minute polling policy.
In order to verify the ICMP/Ping polling frequency the simplest way is to restart fpingd with logging enabled and observe its log in
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
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.