Cisco Router CPU Usage
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.
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:
- 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.
- Download cacti-cisco-cpu.0.9e.tar.gz to a temporary directory on the Cacti server machine.
- 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. - Copy scripts/ss_cisco_cpu_usage.php to the <cacti>/scripts/ directory.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- hostname: The domain name or IP address of the target device. This value is mandatory.
- version: The version of SNMP to use. The remaining parameter values will be verified against this value, and is mandatory.
- community: The SNMP community string to use. If version 1 or 2 was specified, the community string must be provided. If version 3 was specified, this value will be ignored.
- v3 username: Part of the credentials for SNMP v3 queries. If version 1 or 2 was specified, this value will be ignored.
- v3 password : Part of the credentials for SNMP v3 queries. If version 1 or 2 was specified, this value will be ignored.
- v3 authentication protocol : Part of the credentials for SNMP v3 queries. If version 1 or 2 was specified, this value will be ignored.
- v3 privilege password : Part of the credentials for SNMP v3 queries. If version 1 or 2 was specified, this value will be ignored.
- v3 privilige protocol : Part of the credentials for SNMP v3 queries. If version 1 or 2 was specified, this value will be ignored.
- v3 authentication context : Part of the credentials for SNMP v3 queries. If version 1 or 2 was specified, this value will be ignored.
- port number: The UDP port number for the SNMP daemon on the target device. If a value is not specified, the default value of "161" will be used.
- timeout: The number of seconds to wait for the SNMP query to be executed. If a value is not specified, the Cacti configuration will be read for a locally-defined default value.
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:
- index: This request asks for a list of CPU device identifiers. No additional input data is needed. The response data is provided as a series of index values, with each CPU being enumerated on a separate response line.
- query <fieldname>: This request asks for the specified field data associated with each CPU device. The response data is provided as "index:data" pairs, where the index value is the primary device identifier, and the data value is the requested field data as available.
- get <fieldname> <cpu>: This request asks for the specified field data associated with the specified CPU device. The requested data is provided by itself with no other accompanying information.
The field names that can be used in "query" or "get" requests are as follows:
- cpudevice: The index value for the CPU(s).
- cpuname: A human-friendly short name for the CPU(s). Currently this is just a string containing "CPU" followed by the CPU index number (eg, "CPU1").
- cpudesc: A longer description of the hardware component associated with the CPU(s), as obtained by querying for the supplemental data. If a description string is not available in the MIB, the script generates a string containing "Unlabelled CPU" followed by the index number.
- onemin: The last one minute of CPU activity, shown as a percentage of available utilization.
- fivemin: The last five minutes of CPU activity, shown as a percentage of available utilization.
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