---------------------------------------------

Cisco Router CPU Usage

November 11, 2010

Cisco routers with IOS 12.1 and higher have indexed SNMP tables that provide multiple usage statistics for each of the individual CPUs in the router chassis. In particular, the SNMP table stores percent-utilization readings for each individual CPU, with each sample reflecting the past five seconds, 60 seconds, and 300 seconds of utilization levels.

In order to accurately capture that information in Cacti, this script template enumerates each of the router CPUs, determines the relevent component name if possible, and then captures the one- and five-minute utilization readings for each selected processor (the five-second sample is ignored due to the small interval). For illustration purposes, the graph at right shows the CPU usage for a small router with a single CPU.

Figure 1
Figure 1

Note that a PHP script is used to retrieve this information, as opposed to basic SNMP lookups, for two reasons. First, Cisco changed the way that the readings are calculated and also changed the OIDs where they were stored, and in some cases the script will have to fall back to the old method if the new data is not available. Furthermore, each CPU has a type identifier which must be matched to a long name or given a generic name if no match is found, and that is really only possible with a script.

Installation

To use this script template, perform the following steps:

  1. Enable SNMP on the Cisco router and verify that the Cacti management station has sufficient access privileges to read the data by using the snmpwalk utility to list all of the MIBs under the 1.3.6.1.4.1.9.9.109.1.1.1.1 branch on the target device.
  2. Download cacti-cisco-cpu.0.9e.tar.gz to a temporary directory on the Cacti server machine.
  3. Expand the archive with the command tar -xvzf cacti-cisco-cpu.0.9e.tar.gz, and change to the cacti-cisco-cpu directory that is created.
  4. Copy scripts/ss_cisco_cpu_usage.php to the <cacti>/scripts/ directory.
  5. If the server is running Cacti 0.8.6, copy resource/0.8.6/cisco_cpu.xml to the <cacti>/resource/script_server/ directory, or if the server is running Cacti 0.8.7, copy resource/0.8.7/cisco_cpu.xml to the <cacti>/resource/script_server/ directory.
  6. Access the Cacti installation in a web browser, click on the "Import Templates" menu item on the left side of the Console screen, and import the template/cisco_cpu_data_query.xml file. Cacti should automatically create the required data query, graph template, and data template objects.
  7. Click on the "Data Queries" menu item on the left side of the Console screen and verify that a "Cisco Router - CPU Usage" data query is present. Click the name of the object and verify that Cacti was able to locate and read the XML resource file that was installed in step 6 above.
  8. Click on the Devices menu item on the left side of the Console screen, select a Cisco router device, and scroll down to the "Associated Data Queries" table at the bottom of the screen. Select "Cisco Router - CPU Usage" in the "Add Data Query" drop-down box, and click the "Add" button.
  9. After the Device screen reloads, verify that the "Cisco Router - CPU Usage" data query is present, and then click the "Create Graphs for this Host" link at the top of the page.
  10. Once the screen finishes loading, locate the "Cisco Router - CPU Usage" data query, select the CPUs that you want to monitor, and click the "Create" button at the bottom of the screen to include them in the polling process.

Note: these files are intended to be used with Cacti 0.8.6 and 0.8.7 and PHP 5.2, and may not operate as expected with other versions.

Script Input and Output

In some cases you may want to execute the script file manually for debugging purposes. The parameters to the script use a fixed structure that is optimized for use with the Cacti poller, but also allows for human interaction. In particular, the script uses three parameter groups, with the exact structure depending on the SNMP version in use and the output that is desired.

The first parameter group provides an SNMP protocol "bundle" of the following values, separated by colon characters: In those cases where a value is unneeded (such as SNMP v3 authentication credentials for an SNMP v2 query), or where a default value is adequate (such as the SNMP port number), the value can be omitted.

Taken as a whole, a valid SNMP bundle for the localhost device using SNMP v2 with the community string of "public" on the default port number and a default timeout would be "localhost:2:public::::::::".

The next parameter identifies the type of Cacti data that is being requested. Cacti uses "index" queries to enumerate all of the entries for a data query template, and then uses various kinds of "query" queries to obtain extended information about those entries (such as the full name of each indexed entry). Separately, the Cacti poller uses "get" queries to fetch the readings for each specific entry (again, keyed by index value). Note that he index and query operations are typically only performed when the device entry is being created or modified, and the get operations provide the actual readings to the poller. This script parameter must be one of those query types, with any remaining parameters providing any necessary supplemental data. Specifically the request parameters are one of the following:

The field names that can be used in "query" or "get" requests are as follows:

You must know the index value that has been assigned to a device before you can ask for details about that specific device. To do this, you can use the "query cpudesc" request to get a list of CPUs and their component descriptions, and then use the "get <fieldname> <cpu>" request to get information about the desired CPU. The full command lines for these requests, using example data from above, are shown below:

$ php ss_cisco_cpu_usage.php hostname:2:public:::::::: query cpudesc
1:Unlabelled CPU 1
3:Unlabelled CPU 3

$ php ss_cisco_cpu_usage.php hostname:2:public:::::::: get onemin 1
8
-- 30 --
Copyright © 2010-2017 Eric A. Hall.
---------------------------------------------