Table rows contain the logical entities and one column corresponds to each variables. The table representation is like this:
RFC1213-MIB::ifTable(2).ifEntry(1).ifDescr(2).33 = STRING: GigabitEthernet0/0/0/18 RFC1213-MIB::ifTable(2).ifEntry(1).ifDescr(2).106 = STRING: TenGigE0/4/0/3 RFC1213-MIB::ifTable(2).ifEntry(1).ifDescr(2).418 = STRING: Bundle-Ether1 RFC1213-MIB::ifTable(2).ifEntry(1).ifInOctets(10).33 = Counter32: 984015092 RFC1213-MIB::ifTable(2).ifEntry(1).ifInOctets(10).106 = Counter32: 2797705123 RFC1213-MIB::ifTable(2).ifEntry(1).ifInOctets(10).418 = Counter32: 3777720296 RFC1213-MIB::ifTable(2).ifEntry(1).ifOutUcastPkts(17).33 = Counter32: 443013466 RFC1213-MIB::ifTable(2).ifEntry(1).ifOutUcastPkts(17).106 = Counter32: 27951219 RFC1213-MIB::ifTable(2).ifEntry(1).ifOutUcastPkts(17).418 = Counter32: 2086888160
Model of Entity-MIB follows physical (and logical) hierarchy of nested entities. Data is organized into trees. (We are only interested in physical hierarchy now.)
The tree contains each component of the current harware configuration. Root of the tree is the chassis (i.e. the heavy metal box providing physical location for power supplies, fans, processor and interface cards etc. :-) meanwhile leaves are "atomic" things like voltage or temperature sensors. In our point of view intermediate nodes are just for containers for more interesting entities and have no dynamic data that we could collect. All nodes have a unique integer id called entPhysicalIndex.
Now what data we want to gather? Modern hardware is full of various sensors providing info about voltages, currents, power consumption, temperature, transmitted and received optical power, failure states etc. Main monitored components e.g. optical TenGigaBit interface and power supply have very different characteristics. Both have temperature and (different number of) voltage sensors but received optical power is not applicable to power supply as well as we cannot speak about fan rev in TenGigaBit context. So there is no standard set of sensors related to a "typical" hardware unit because there is no typical hardware.
Therefore the relationship between monitored hardware units and sensors is indirect. A HW unit is a subtree of entity tree and sensors are leaves of it.
Actual measured values come from CISCO-ENTITY-SENSOR-MIB (that is a classical table) addressed by the above entPhisicalIndex as instance number.
Unfortunately Cricket cannot handle this situation without external scripts. A usual target like an optical transceiver has its own entPhysicalIndex as well as its children. But these numbers are totally unrelated. Mapping functionality can retrieve only instance number of the target but not of individual datasources. In other words instance number (referred az %inst% in config, 14925760 on the figure) is unusable in datasource definitions like this:
dataSource ifInOctets
ds-source = snmp://%snmp%/ifInOctets.%inst%
dataSource ifOutOctets
ds-source = snmp://%snmp%/ifOutOctets.%inst%
dataSource ifHCInOctets
ds-source = snmp://%snmp%/ifHCInOctets.%inst%
dataSource ifHCOutOctets
ds-source = con snmp://%snmp%/ifHCOutOctets.%inst%
We should use different (and unpredictable) instance numbers in our case:
OID entSensorValue 1.3.6.1.4.1.9.9.91.1.1.1.1.4 # 53842121 on the figure dataSource Temp ds-source = snmp://%snmp%/entSensorValue.%inst_of_temp_sensor% # 37064572 on the figure dataSource Bias ds-source = snmp://%snmp%/entSensorValue.%inst_of_current_sensor% # 3510870 on the figure dataSource TxPower ds-source = snmp://%snmp%/entSensorValue.%inst_of_txpower_sensor% # 20286959 on the figure dataSource RxPower ds-source = snmp://%snmp%/entSensorValue.%inst_of_rxpower_sensor%