Feature Request: Support for SNMP tables where the index is not the last part of the OID

[Etzeitet]

While building a ZenPack, I have come across a number of SNMP tables on my target devices that are not indexed in a way that supports the current way of building Components.

In a typical SNMP table, you have something like:

Table OID	Column	Index
1.2.3.4.5.100	.1	.1
1.2.3.4.5.100	.1	.2
1.2.3.4.5.100	.2	.1
1.2.3.4.5.100	.2	.2

This is all fine and the usual modelling methods work just fine (using GetTableMap etc). However, I have tables like this:

Table OID	Column	Index	Column
1.2.3.4.5.100	.1	.22	.1
1.2.3.4.5.100	.1	.22	.2
1.2.3.4.5.100	.1	.43	.1
1.2.3.4.5.100	.1	.43	.2

As you can see, the index I am interested in is not the last part of the OID. The columns are still fixed and predictable.

It is difficult to model the device, as you cannot create the GetTableMap objects without knowing the index... and you don't know the index until you have collected the SNMP data.

Even if I did know the index ahead of time, or I use a custom script/code to collect the SNMP data, I can't do much with it in the monitoring templates. From my inspection of the zenperfsnmp code, it is pretty much hardwired to build the full OID from the base OID in the SNMP datasource and appending the snmpindex attribute of the component onto the end.

I did find out about a component's snmpindex_dtc attribute, but this again assumes the index is the last part of the OID.

What I would like to see is a collection mechanism for the modeler plugins that allows collection of arbitrary tables, without having to specify a column map (essentially a "blind" snmpwalk from the provided table OID).

Second, it would be nice if there were an SNMP datasource that supported custom OID construction options. That could take the form of something like a TALES expression, for example: 1.2.3.4.5.100.1.${here/snmpindex}.1, or it could be a placeholder so Zenoss knows where to insert the snmpindex attribute: 1.2.3.4.5.100.1.<snmpindex>.1.

If there are already mechanisms for what I am trying to achieve, please do let me know!

[dougsyer]

Your index doesnt need to be a single digit its a string so it can be 1.2.3.45.4. If you split the table to the left more, i think it will work..if I understand what you are asking correctly...

If you have a situation where the index of your compontmts Update between models like with cisco wap and vpn tunnels then you can write a zenpython plugin to update the snmp indexes and just let zenperfsnmp do the polling. Ive had to do that several times.

As you said the _dct attribute works when you habe the same index in multiple Tables.

This is sort of an aside.. If your situation is that they are essentially trying to create a 3d table out of a single table rather than using two joined tables then often i need to model two parent child component types in order to make the model Work and stats polling sane..if the model is off you can really bang your head against the wall. Ive also use a simpe zencommand snmp plugin using twisted for situations where scalability isnt as much of a concern..

[Etzeitet]

I realise the snmpindex attribute is a string. This could be useful in future, but for my use-case I don't think it helps.

A simplified version of one of the tables I am dealing with looks like this:

Table OID	SIP Method	Interface Index	Message Type
1.2.3.4.100	register (.1)	.27	msg_sent (.1)
1.2.3.4.100	register (.1)	.27	rsp_sent (.2)
1.2.3.4.100	register (.1)	.33	msg_sent (.1)
1.2.3.4.100	register (.1)	.33	rsp_sent (.2)
1.2.3.4.100	subscribe (.2)	.27	msg_sent (.1)
1.2.3.4.100	subscribe (.2)	.27	rsp_sent (.2)
1.2.3.4.100	subscribe (.2)	.33	msg_sent (.1)
1.2.3.4.100	subscribe (.2)	.33	rsp_sent (.2)

The details of the Interface can be found in another table which is simple enough to grab. However, modelling this table using GetTableMap doesn't seem possible.

GetTableMap requires a column map, which in a normal SNMP table would be the OID just prior to the index of a row. In my example table, this doesn't work. I thought of extending GetTableMap to add the logic I needed, or using my Plugin's __init__() method to build the table map as the Plugin is instantiated. However, I don't have access to the device in the __init__ method. So, without completely changing the way the zenmodel script works, this is a bit of a no go.

I have created a Python plugin which runs some code to grab the data from SNMP itself. This is fine and I can model this table no problem. However, I still can't create a standard SNMP datasource for these components to grab the message type data, as the unique index for each component item is not the last part of the OID.

Ideally I would like to able to specify where Zenoss inserts the index into the provided OID. I don't think the tables in question are trying to be overly clever, the vendor just chose a weird ordering of the OID. If I wanted to model by Message Type, I could make it work, but that's not how the interested parties want to view these details.