Raritan Computer COMMANDCENTER NOC - Manual (Page 129)

APPENDIX B : TROUBLESHOOTING 117
from the CC-NOC to the device and that TCP and UDP are working. If you have already
performed the troubleshooting steps for Pollers and Capability Scanning on the node in question,
you have adequately tested this. If you are having trouble with vulnerability scanning, try the
troubleshooting steps below:
1. If you are not getting vulnerability information, make sure that you set the scan parameters
correctly in Admin-> Vulnerability Scanning Configuration.
2. If you are only getting open port information, make sure you have configured vulnerability
scanning for at least Level 2 scans.
3. If you configured Level 3 and 4 to run, make sure you are not targeting mission critical
devices before pressing the [perform scan now] button.
4. If you have devices that are being adversely impacted by vulnerability scanning, you can
exclude them from scanning. Visit the Admin-> Vulnerability Scanning Configuration
page and enter their IP addresses in the exclude list.
In addition to these troubleshooting steps, you can get overall vulnerability information from the
Vulnerabilities tab. For details on vulnerabilities for specific nodes and interfaces, visit the node
and interface pages.
Historic Data and Graphs
Troubleshooting historic data and graphs is usually more about understanding the calculations
than it is about troubleshooting. If, after understanding the items in this section, you still believe
that your data is incorrect, please contact Technical Support with as much information as you can
provide, for example, sample reports, time of day, the values you expected, etc. Since most issues
with reports are usually presented as a question, rather than a problem, each section in this
chapter will cover a common question. In our next section, we will return to the normal
troubleshooting format.
How is Performance Data Summarized?
Performance data is the best example of summarization. As data is collected, it is relevant in its
most granular form only for a little while. Later, more broad generalizations, for example,
averages, minimums, and maximums, are most important. For example, a router’s CPU
performance is collected every 5 minutes. If you are looking to fix immediate problems, you
might be interested in that 5-minute granularity, viewed over the last two hours. However, if you
are looking for CPU performance trending and historical usage information, a view of that data
over the period of one year to 6 months ago is probably more relevant, and for that view you
don’t need 5-minute granularity. Raritan aggregates data once it reaches one month old, but
archives it for a full year, making it available for these types of long-range reports.
How are Service Level Availabilities Calculated?
It's easiest to envision this number as number of successful polls divided by the number of
attempted polls over the past 24 hours:
Successful polls over past 24 hours = SLA percentage Attempted polls over past 24 hours
The calculation is completed over a rolling 24 hour window, and the window size of 24-hours is
not a user-configurable parameter.
Why isn’t SNMP Part of my Service Level Availability Calculations?
When development of the Raritan network management technologies began, a decision was made
that the service level availability calculation should reflect the availability of services that can
potentially impact the core business of the company. In most cases, the inability to poll for SNMP
data is not integral to the core business of a company, thus it is excluded from the calculation.