Followup to Spectrum Optimization and Customization Class: Understanding Spectrum Polling before increasing polling load with Watches.

Document created by macad02 Employee on Aug 10, 2017
Version 1Show Document
  • View in full screen mode

In module 5 of the Optimization and Customization class we learned to periodically poll external attributes to check values against a threshold.

We use "Watches" to do this.

 

 

When we create a Watch to watch an external attribute, we increase the polling overhead on the SpectroSERVER.

 

Therefore, before we cause Spectrum to do MORE polling, we should understand what Spectrum is polling by default.

If we look at any model attributes we can filter on "EP " (that is an "E", "P", and a space " ") which will show up which attributes have the "poll" flag set to be polled periodically.

You will notice that for the Cisco Router, Enterasys Switch and Windows Server, there are the same 7 polled attributes. These 7 will be common for ALL device models. For the Cisco Router model, you might notice that there is 1 extra Cisco vendor specific attribute polled:
ccmHistoryRunningLastChanged (0x210b66)

For some specialized Model Types (like rtr_cisco) there might a few, 1-4, vendor specific attributes polled.

 

There is another way of showing periodically polled attributes. This is using a executable in the SS-Tools directory called "LogPollAnalyzer"

This tool specifically shows which attributes are periodically polled by Model Type.
You will notice there there are 2 more attributes that are being polled for each device Model Type:
NRM_DeviceMemoryUtilization (0x12ac6)
NRM_DeviceCPUUtilization (0x12aaa)

To lauch the LogPollAnalyzer use the following command from the $SPECROOT/SS-Tools direcotry (the "-l" is a dash lower case L and the hex code is the landscape handle of SS):
LogPollAnalyzer -l 0x1000000


These are special "normalized" attributes that are actively polling CPU and Memory Utilization on all device models Out-Of-The-Box and check against some default thresholds:

 

You can disable these thresholds on a model by model basis or in bulk with Attribute Editor by setting the Threshold values to zero.

If I set the Theshold Values to Zero for this 1 router, we will see that Spectrum is stop the periodic polling for CPU and Memory Utilization on the 1 router.

 

Running the LogPollAnalyzer again, we will see that 1 model of type RTR_CISCO is not being polled for CPU and Memory Utilization and that 2 models of type RTR_CISCO are being polled for CPU an Memory Utilziation.

As I mentioned before, the polling of CPU and Memory Utilization attributes can be disabled on individual models or on a group of models using Attribute Editor.
You can also disable CPU and Memory Utilization polling/thresholding system wide by setting an attribute on the VNM model. This "Device Thresholds" ONLY affects CPU and Memory Utilization polling/thresholding.

 

Notice the output of the LogPollAnalyzer now shows that NO device models are being polled for CPU or Memory Utilization.

You may want to globally disable device thresholds if you are using some performance tool like CA Performance Management, CA eHealth, CA Netvoyant or CA UIM to collect historic CPU and Memory Performance data and using those tools to send their threshold alerts into Spectrum.

 

 

Creating a Watch that "watches" an external attribute will cause more polling.

I created a watch called "adams_watch" on the RTR_CISCO model type that "watches" the cisco mib object busyPer (0x2100cb 1.3.6.1.4.1.9.2.1.56).

We see that if I activate the watch on a single router, the LogPollAnalyzer will show that only 1 model of type RTR_CISCO is polled for "adams_watch".

For this screenshot, i used the "-i" flag with the LogPollAnalyzer command to show the polling interval for the attributes.

If the watch is activated on all models of type RTR_CISCO things will look like this:

 

 

What is very important to understand about all of the Out-of-The-Box Spectrum polling is the PORTS ARE NOT PERIODICALLY POLLED BY DEFAULT!

No port Model Types show up when the LogPollAnalyzer is run since there are not port attributes with the "P" flag set and no thresholds are set by default on any port models.
All Of this can be changed.

Typically Port polling is enabled by enabling "Live Links" or "Live Pipes" on a "GOLD Pipe". Doing this is really setting a port attribute "ok_to_poll" on the ports on either side of that Gold Pipe. This will cause Spectrum to periodically poll those 2 ports for ifOperStatus and ifAdminStatus.

So the LogPollAnalyzer will show only 2 models of type Gen_IF_Port to be polled for
ifOperStatus (0x10e40)
ifAdminStatus (0x10e3f)

And if i enable Live Links on 3 links, that will be a total of 6 polled ports:

If I enable any of the Out-of-The-Box PORT thresholds, that will enable more port polling.
Here I will enable a "% Total Utilization" Threshold on a single port.

The LogPollAnalyzer will show us the extra polling on that Single port.

The lesson to be learned here is the by default, Spectrum polls very few attributes.

This is why it is so important to have your network devices configured to send TRAPS to the Primary and Redundant SpectroSERVERs.

It is also important to know you can change Spectrum Polling behavior by enabling or disabling certain features.

Watches can easily be created that increase the polling load where is severely impacts the performance of the SpectroSERVER if done incorrectly.

2 people found this helpful

Attachments

    Outcomes