Skip to end of banner
Go to start of banner

NMIS - Polling Policy - Configuring Variable Polling Polices

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 26 Current »

Feature Description

Starting with NMIS 8.6.2a user-defined polling polices 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 could be added by editing conf/Table-Polling-Policy.nmis and fractional frequency settings (e.g. 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 old standard 5 minute frequency unless explicitely overridden.

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

Compatibility

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

ICMP/Ping

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.

Concurrent SNMP and WMI

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:

  • 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:

  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.

Candiate selection

Whenever an NMIS collect cycle starts, only the nodes whose last poll was  longer ago 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 closely 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 would 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 this window polling polices 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 step is optional, 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.

  • 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.

[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.

 

  • No labels