Example: Cisco CoreUsage
This example will show up how to retrieve CPU per core metrics from a Cisco Device, based on complex MIB - CISCO-PROCESS-MIB
Only valid on 0.9+
- Example: Retrieve metrics from Cisco CPMCore - CISCO-PROCESS-MIB
- 0 Prerequisites : What and from we are going to collect our data?
- 0.1 SNMP Device model
- 0.2 Select metrics to collect data
- 0.2.1 CPU Total usage
- 0.2.1 CPU per Core usage
- 0.2.2 Indexes
- 0.3 Measurements
- 1 Configuring metrics
- 2 Configuring measurements
- 2.1 Overview
- 2.2 Index 0 | Cisco module
- 2.3 Index 1 | Core Index
- 3 Configuring Measurement Group
- 4 Configuring Device
- 5 Reload configuration
- 6 Check your results!
- 0 Prerequisites : What and from we are going to collect our data?
In order to select the correct metrics for our device, we must check first what model it is. If you don't know the model, you can pre-add the device on SNMP Device Component and do a test connection. To do that:
- Click on
SNMP Devicemenu item - A table with configured devices will show up. Press "New" button or edit an existing one to access to the configuration form.
- Fill the device with the basic connection information
- If everything is OK, you will be able to do a "Test Connection". This button will show up a console with System information of the Device.
To define the metrics to retrieve data from we need first to analyze how CISCO-PROCESS-MIB works
According to the documentation, a single Cisco Switch/Router can have multiple CPUs (not core related)
The CpmCPUTotalEntry will allow us to retrieve the overall usage:
| Entry | OID | Description |
|---|---|---|
cpmCPUTotal1min |
.1.3.6.1.4.1.9.9.109.1.1.1.1.4 | The overall CPU busy percentage in the last 1 minute period. This object obsoletes the avgBusy1 object from the OLD-CISCO-SYSTEM-MIB. This object is deprecated by cpmCPUTotal1minRev which has the changed range of value (0..100). |
The entry of CPUTotal1min will use a single index that can be correlated with the entry: cpmCPUTotalPhysicalIndex
| Entry | OID | Description |
|---|---|---|
cpmCPUTotalPhysicalIndex |
.1.3.6.1.4.1.9.9.109.1.1.1.1.2 | The entPhysicalIndex of the physical entity for which the CPU statistics in this entry are maintained. The physical entity can be a CPU chip, a group of CPUs, a CPU card etc. The exact type of this entity is described by its entPhysicalVendorType value. If the CPU statistics in this entry correspond to more than one physical entity (or to no physical entity), or if the entPhysicalTable is not supported on the SNMP agent, the value of this object must be zero. |
To follow up with this document, we will identify that index as PhysicalIndex
On some devices the cpmCore entry is present and available to have a detail usage for each core, furthermore to the CPU Total usage
In this case, the table where the data is exposed is the entry: cpmCoreEntry that will let us to retrieve the desired data of usage per core on the last 1 minute:
| Entry | OID | Description |
|---|---|---|
cpmCore1min |
.1.3.6.1.4.1.9.9.109.1.1.2.1.4 | The overall Core busy percentage in the last 1 minute period. |
The entry of cpmCore1min has a double entry that will let us to know of what CPU is retrieved and the core number
| Entry | OID | Description |
|---|---|---|
cpmCorePhysicalIndex |
.1.3.6.1.4.1.9.9.109.1.1.2.1.2 | The entCorePhysicalIndex of the physical entity for which the Core statistics in this entry are maintained. The physical entity can be a CPU chip, a group of CPUs, a CPU card etc. The exact type of this entity is described by its entPhysicalVendorType value. If the Core statistics in this entry correspond to more than one physical entity (or to no physical entity), or if the entPhysicalTable is not supported on the SNMP agent, the value of this object must be zero. |
So, the double index will a concatenation of PhysicalIndex and CoreIndex: .[PhysicalIndex].[CoreIndex]
As a brief, the cpmCoreEntry will be indexed by a pair of values which:
.[PhysicalIndex].[CoreIndex]
| Index | Description | Example |
|---|---|---|
PhysicalIndex |
The related core PhysicalIndex | .10 |
CoreIndex |
The related CoreIndex | .2 |
Example of index:
.[10].[0] - The CPU of CPU 1 and the core 0
.[10].[1] - The CPU of CPU 1 and the core 1
.[11].[0] - The CPU of CPU 2 and the core 0
.[11].[1] - The CPU of CPU 2 and the core 1As we have seen, each core needs specific tags to identify those metrics and, based on that they are double indexed, we will create a single measurement to retrieve the required indexes
Available metrics are defined on cpmCPUTotalEntry - 1.3.6.1.4.1.9.9.109.1.1.1.1.
In our example we will configure the following metrics:
| ID | Field Name | IsTag | DataSrcType | GetRate | Base OID/Extradata | Scale | Shift |
|---|---|---|---|---|---|---|---|
| cisco_cpmCore1min | cpmCore1min | false | Gauge32 | false | .1.3.6.1.4.1.9.9.109.1.1.2.1.4 | 0 | 0 |
ℹ️ Cisco CPU per core usage metrics configuration
As we have said, each metric will have a double index: [PhysicalIndex].[CoreIndex]
Let's start to define the measurement
As we have defined, the Core entry needs the following tags to identify each metric:
- CPU module
- CPU core number
- PolicyMap Name
The main problem here is that each tag is being retrieved with different indexes and different indexes dimension, so in order to correlate those tags and indexes we need to define a Multi Index Measurement
To do that, go to Influx Measurements section and click on +New
Fill the ID and Name fields with:
| Field | Value | Description |
|---|---|---|
| ID | cisco_cpmCore | Unique SNMPCollector internal identifier of measurement |
| Name | cpmCore | Measurement name that will be used |
ℹ️ Measurement config section
On the GetMode field select:
| Field | Value | Description |
|---|---|---|
| GetMode | (snmp Table) Multiple indexes | -- |
ℹ️ Measurement get mode
The first that we need to retrieve is the cisco module related tags. According to documentation, we need to poll the following OIDs to retrieve those tags:
| Name | OID | Index |
|---|---|---|
| cpmCPUTotalPhysicalIndex | 1.3.6.1.4.1.9.9.109.1.1.1.1.2 | entPhysicalName Index |
ℹ️ entPhysicalName index
A simple walk on this OID gives as value the physicalIndex on entPhysicalName
> cpmCPUTotalPhysicalIndex: 1.3.6.1.4.1.9.9.109.1.1.1.1.2
.1.3.6.1.4.1.9.9.109.1.1.1.1.2[.19] = INTEGER: 1000
.1.3.6.1.4.1.9.9.109.1.1.1.1.2[.20] = INTEGER: 2000Note that the [.19] and [.20] will be used on the following indexes definition as PhysicalIndex
The value of 1000 and 2000 are the index that allow us to correlate with entPhysicalName index, so, if we retrieve data from the entPhysicalName using that index we will be able to retrieve the related physicalName of the CPU:
> entPhysicalName: .1.3.6.1.2.1.47.1.1.1.1.7
.1.3.6.1.2.1.47.1.1.1.1.7[.1000] = "Switch 1"
.1.3.6.1.2.1.47.1.1.1.1.7[.2000] = "Switch 2"As we have an indirect tag, we will create an index with "(snmp Table) Indexed with indirect Tag"
And will fill with the following fields:
| Field | Value | Description |
|---|---|---|
| Index Label | cpmCPUTotalPhysicalIndex | Unique SNMPCollector internal identifier of measurement |
| Index Description | Index to retrieve CPU name from entPhysicalName | -- |
| Index Base OID | .1.3.6.1.4.1.9.9.166.1.1.1.1.4 | Base OID is the cpmCPUTotalPhysicalIndex which gives us the value of the entPhysicalName |
| Index Tag OID | .1.3.6.1.2.1.31.1.1.1.1 | entPhysicalName TagOID that will match with cpmCPUTotalPhysicalIndex result |
| Index Tag | cpuPhysicalIndex | We will use directly the name of the field that is being retrieved, but you can set whatever you want as your Tag Key |
| Index Tag Format | -- | We don't need to format the ifName tag, but you are free to set up whatever you want! |
| Index Dependency | -- | We don't need a dependency as it will be the first OID to retrieve tag from |
ℹ️ Index 0 - cpmCPUTotalPhysicalIndex
The final output map of pairs [index]:[tag] will be:
> Index: IDX{0} | cpmCPUTotalPhysicalIndex
[.10] = "Switch 1" || cpuPhysicalIndex
[.20] = "Switch 2" || cpuPhysicalIndexOnce we have the first indexes - Physical Index that gives us of what CPU is related, we need to retrieve the values of the other index, the Core Index.
| Name | OID | Index |
|---|---|---|
| cpmCorePhysicalIndex | .1.3.6.1.4.1.9.9.109.1.1.2.1.2 | [Physical Index].[Core Index] |
A simple walk on this OID gives us the core number of the CPU
> cpmCorePhysicalIndex: .1.3.6.1.4.1.9.9.109.1.1.2.1.2
.1.3.6.1.4.1.9.9.109.1.1.2.1.2[.19][.0] = INTEGER 0
.1.3.6.1.4.1.9.9.109.1.1.2.1.2[.19][.1] = INTEGER 1
.1.3.6.1.4.1.9.9.109.1.1.2.1.2[.19][.2] = INTEGER 2
.1.3.6.1.4.1.9.9.109.1.1.2.1.2[.19][.3] = INTEGER 3
.1.3.6.1.4.1.9.9.109.1.1.2.1.2[.20][.0] = INTEGER 0
.1.3.6.1.4.1.9.9.109.1.1.2.1.2[.20][.1] = INTEGER 1
.1.3.6.1.4.1.9.9.109.1.1.2.1.2[.20][.2] = INTEGER 2
.1.3.6.1.4.1.9.9.109.1.1.2.1.2[.20][.3] = INTEGER 3
In this case, we don't need to do an indirection, as it is giving directly the value of the tag, so we can use a "(snmp Table) Index with direct TAG"
As we can see, in this case we have the pair of indexes
We will fill the index with the following field/values:
| Field | Value | Description |
|---|---|---|
| Index Label | cpmCorePhysicalIndex | Unique SNMPCollector internal identifier of measurement |
| Index Description | Index to retrieve the core number from cpmCorePhysicalIndex | -- |
| Index Base OID | .1.3.6.1.4.1.9.9.109.1.1.2.1.2 | Base OID is the cpmCorePhysicalIndex which gives us the core num,ber |
| Index Tag | coreNumber | We will use directly the name of the field that is being retrieved, but you can set whatever you want as your Tag Key |
| Index Tag Format | -- | We don't need to format the coreNumber tag, but you are free to set up whatever you want! |
| Index Dependency | IDX{0};DOT[0:0];SKIP | (*) |
ℹ️ Index 1 - cpmCorePhysicalIndex
(*) Dependency:
We set up a dependency with the IDX{0}, as they shares the same Index in order to heridate ifIndex Tags. We will use a SKIP strategy
At this point, we will have that the IDX{1} will be:
> Index: IDX{0} | cpmCPUTotalPhysicalIndex
[.19] = "Switch 1" || cpuPhysicalIndex
[.20] = "Switch 2" || cpuPhysicalIndex
> Index: IDX{1} | cpmCorePhysicalIndex | IDX{0};DOT[0:0];SKIP
[.19][.0] = "Switch 1" | "0" || cpuPhysicalIndex | coreNumber
[.19][.1] = "Switch 1" | "1" || cpuPhysicalIndex | coreNumber
[.19][.2] = "Switch 1" | "2" || cpuPhysicalIndex | coreNumber
[.19][.3] = "Switch 1" | "3" || cpuPhysicalIndex | coreNumber
[.20][.0] = "Switch 2" | "0" || cpuPhysicalIndex | coreNumber
[.20][.1] = "Switch 2" | "1" || cpuPhysicalIndex | coreNumber
[.20][.2] = "Switch 2" | "2" || cpuPhysicalIndex | coreNumber
[.20][.3] = "Switch 2" | "3" || cpuPhysicalIndex | coreNumber
Go to menu and click over Measurement Group section
Create a + New Measurement Group and fill it with:
| Field | Value | Description |
|---|---|---|
| ID | Cisco_CoreCPU | The unique internal ID to identify the Measurement Group |
| Measurements | cisco_cpmCore | Measurement from cisco_cpmCore |
ℹ️ Cisco_cpmCore measurement group with cpmCore stats entry
Attach your new measurement group and filters to the existing Device enabled
In order to reload configuration you must click on the menu item Reload Config. Once the SNMP Collector will receive the signal and it will try to reload all configuration. During that process you won't be able to navigate until the process is finished.
See what are you collecting from the Runtime component!
- Click on
Runtimemenu item - Find your device and check if its actived and connected. If not, check your connection data!
- Click on the eye icon and see what are you collecting!!!
