[Feature request] Allow indexed ID to be specified in the middle of OID for SNMP metric

[dhoutz]

Hi,

I'm currently trying to poll our Raritan PDUs to get per outlet metrics however I've run into an issue due to the OID layout that Raritan uses. Unlike most indexed tables I've dealt with, such as ifTable, where the indexed instance is appended to the end the of the OID, Raritan puts the index mid OID.

For example, to get the current Watts being pulled from an outlet you would use:

.1.3.6.1.4.1.13742.6.5.4.3.1.6.1.<OUTLET#>.5

To get the current for outlet:

1.3.6.1.4.1.13742.6.5.4.3.1.6.1.<OUTLET#>.1

In this case the specific outlet on the PDU (1-24) comes before the counter (5 for Watts, 1 for Current).

Unless I'm overlooking something this makes it impossible to define an SNMP metric with the OID and then define an Influx Measurement with a GetMode Indexed SNMP Table.

I think this could be solved by defining where the index goes in the OID when defining a new SNMP metric. Currently I believe they are just added to the end.

Link to Raritan SNMP MIB Doc: http://support.raritan.com/px2/version-3.0.0/PX2_MIB_Guide.pdf

Section

[jackson-tim]

+1

[tomeknet]

+1

[pstanczak]

+1

[tardoe]

I actually came across the exact same issue with Raritan PDUs… Definitely another +1 for this.

• Tim

On 12 Feb 2018, at 12:58 pm, Dan Houtz [email protected] wrote:

Hi,

I'm currently trying to poll our Raritan PDUs to get per outlet metrics however I've run into an issue due to the OID layout that Raritan uses. Unlike most indexed tables I've dealt with, such as ifTable, where the indexed instance is appended to the end the of the OID, Raritan puts the index mid OID.

For example, to get the current Watts being pulled from an outlet you would use:

.1.3.6.1.4.1.13742.6.5.4.3.1.6.1.<OUTLET#>.5

To get the current for outlet:

1.3.6.1.4.1.13742.6.5.4.3.1.6.1.<OUTLET#>.1

In this case the specific outlet on the PDU (1-24) comes before the counter (5 for Watts, 1 for Current).

Unless I'm overlooking something this makes it impossible to define an SNMP metric with the OID and then define an Influx Measurement with a GetMode Indexed SNMP Table.

I think this could be solved by defining where the index goes in the OID when defining a new SNMP metric. Currently I believe they are just added to the end.

Link to Raritan SNMP MIB Doc: http://support.raritan.com/px2/version-3.0.0/PX2_MIB_Guide.pdf http://support.raritan.com/px2/version-3.0.0/PX2_MIB_Guide.pdf Section

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/toni-moreno/snmpcollector/issues/324, or mute the thread https://github.com/notifications/unsubscribe-auth/AFFaS2mPyLU1nGQL-T_vVXhRYFLlE030ks5tT5rQgaJpZM4SBnd2.

[mikemrm]

+1

[sbengo]

Hi guys,

Sorry for the late answer and thanks for the explanation. This feature was already asked on #252 (last comment) and I personally think that could be achieved setting up a new field called "Metric Suffix" which would be appended at the index.

As I answered on the related issue, this feature requires a huge change on the core metric/measurement behaviour, we are thinking on it, but it would take some time to do it

Thanks for the patience!! Regards!

[jasonyates]

+1 for this.

I have a similar issue with Cisco WLC's. The Index is by Access Point name however to pull something like clients per Access Point the information is presented per radio and a .0 and .1 is appended to each OID.

[SteveRodrigue]

+1

In the case of IP SLA, there could even be multiple "dot" after the index...

Here is an example: snmpwalk -v2c -c ***** router.example.com .1.3.6.1.4.1.9.9.42.1.3.2.1.2<INDEX> SNMPv2-SMI::enterprises.9.9.42.1.3.2.1.2.<INDEX>.1694441214.1.1 = INTEGER: 1801 SNMPv2-SMI::enterprises.9.9.42.1.3.2.1.2.<INDEX>.1694801214.1.1 = INTEGER: 1377

[syepes]

+1 Facing the same issue with the Cisco WLC

@jasonyates Did you finalize implementing the WLC collections? If yes would you care in shearing an export of the "Measurement Groups"

[wurmrobert]

+1

[wurmrobert]

@toni-moreno i have about the same requirements on some devices. So i have forked your collector and tried to understand your code and implement a running solution which works fine for my cases.

My solution idea was:

We have a oid like previous discussed from @dhoutz:

.1.3.6.1.4.1.13742.6.5.4.3.1.6.1.<OUTLET#>.5

In my case i have the following oids:

.1.3.6.1.4.1.4491.2.1.20.1.4.1.5.<x>.<y> like .1.3.6.1.4.1.4491.2.1.20.1.4.1.5.1.1 .1.3.6.1.4.1.4491.2.1.20.1.4.1.5.2.2 .1.3.6.1.4.1.4491.2.1.20.1.4.1.5.3.3 .1.3.6.1.4.1.4491.2.1.20.1.4.1.5.2.1 .1.3.6.1.4.1.4491.2.1.20.1.4.1.5.2.2 .. ..

So i created an measurement (indexed with direct tag): IndexOId: .1.3.6.1.4.1.4491.2.1.20.1.3.1.2 IndexTag: mac

This oid gives the first indexes -> variable <x> In @dhoutz example this would be the <OUTLET> example.

I created a metric with the Base OID: .1.3.6.1.4.1.4491.2.1.20.1.4.1.5

After debugging the collector i realized that you fetch all variables correct with the get bulk operation. But you only store one variable in the SnmpMetric struct at the attribute ComputedValue.

So i changed the struct, so that i can store all variables in a map where the key is the first index:

CookedValue map[string]interface{}
CurValue    map[string]interface{}
LastValue   map[string]interface{}

To split indexes with values i had to change the SnmpWalkData method:

func (m *Measurement) SnmpWalkData() (int64, int64, int64, error) {

	now := time.Now()
	var gathered int64
	var processed int64
	var errors int64

	setRawData := func(pdu gosnmp.SnmpPDU) error {
		m.Debugf("received SNMP  pdu:%+v", pdu)
		gathered++
		if pdu.Value == nil {
			m.Warnf("no value retured by pdu :%+v", pdu)
			errors++
			return nil //if error return the bulk process will stop
		}


		if metr, ok := m.OidSnmpMap[pdu.Name]; ok {
			m.Debugf("OK measurement %s SNMP RESULT OID %s MetricFound", pdu.Name, pdu.Value)
			processed++
			metr.SetRawData(pdu, nil, "", now)
		} else {
			var subSet = false
			for k, v := range m.OidSnmpMap {
				var subOids = strings.Split(pdu.Name, k)
				
				
				// get sub oid
				var pduOids = strings.Split(pdu.Name, ".")
				var mOids = strings.Split(k, ".")



				if len(subOids) > 1 && (len(mOids) >= len(mOids)) && (mOids[len(mOids) -1] == pduOids[len(mOids) -1])  {
					// its a sub oid

					var subOid = strings.Join(subOids,"")

					fmt.Println("sub: ", subOid)

					subSet    = true

					metr = v


					m.Debugf("OK measurement %s SNMP RESULT OID %s MetricFound", pdu.Name, pdu.Value)

					processed++
					metr.SetRawData(pdu, subOids, subOid, now)

				}
			}


			if !subSet {
				m.Debugf("returned OID from device: %s  Not Found in measurement /metr list: %+v", pdu.Name, m.cfg.ID)
			}
		}

		return nil
	}

	for _, v := range m.cfg.FieldMetric {
		if err := m.Walk(v.BaseOID, setRawData); err != nil {
			m.Errorf("SNMP WALK (%s) for OID (%s) get error: %s\n", m.snmpClient.Target, v.BaseOID, err)
			errors += int64(m.MetricTable.Len())
		}
	}

	return gathered, processed, errors, nil
}

I had also changed many other methods, like the convertion methods. At the end (most important) i changed the storage of the influxpoints that i get for each leading index a measurement row where i tagged the row with the index:

time                SNR     host                mac                 subIndexes
----                ------- --------------      ----                ------ 
1551438780000000000 363     10.159.201.251      00:00:00:00:00:00   .1
1551438780000000000 361     10.159.201.251      00:00:00:00:00:00   .2
1551438780000000000 362     10.159.201.251      00:00:00:00:00:00   .3
1551438780000000000 363     10.159.201.252      00:00:00:00:00:00   .1
...
...

My questions to you @toni-moreno:

1. Do you think that this implementation is not nonsense?
2. Do you think that this implementation could also be used for this feature request?

[toni-moreno]

Hi @wurmrobert , thanks a lot for your suggestion, and sorry for the delay in the answer.

I think this could be a good staring point, but we need to review first... Could you send us a Pull Request with your changes , please ?

Thanks a lot!

[deejaypro]

Hey, i really would like to see this feature in snmpcollector. Because this prevents us from gathering snmp metrics from a specific vendor. And the Telegraf SNMP Collector isn't that great if i'm honest. @wurmrobert do you thing, that you are able to create a feature request soon or make your fork visibile for others so we can see what changes you made?

[toni-moreno]

Hello @wurmrobert, I would like to release a new version with this new feature.

would be great if you could send us a PR with your changes. ( don't worry if there is some merge conflict) , we can rebase for you.

Thank you very much.

[jjess]

I need this feature as well because of some Qos tables where the Index referring the interface is not located at the end of the OID. For example:

.1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.5.109.0.1 = Counter64: 526551509130967 .1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.5.109.0.2 = Counter64: 0 .1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.5.109.0.3 = Counter64: 22915176814254 .1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.5.109.0.4 = Counter64: 0 .1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.5.109.0.5 = Counter64: 736916480948778 .1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.5.109.0.6 = Counter64: 384464519432 .1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.5.109.0.7 = Counter64: 4446961646 .1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.5.109.0.8 = Counter64: 988307868 .1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.5.109.0.9 = Counter64: 1286773070197087

Where "109" is the interface Index.

BR,

Jes