snmptable with index_order when row order changes

[sspyrison]

Hello,

I would appreciate any pointers here.

Given an Indexed SNMP Query of data returned by something like dskTable or dskIOTable, am I correct that the index is not something static? In other words, after an snmpd restart or a host reboot the order of rows in these tables can change, correct?

In dskTable's case, what I have noticed in testing is that when using

Code: Select all

includeAllDisks

the order can change, but if I apply each disk specifically, it seems to be consistent. I would prefer to use

Code: Select all

includeAllDisks

because it simplifies deployment across many hosts, and then I can pick and choose what I want from within Cacti.

I suspect this is a solved problem and I am just not picking up on the solution yet... at least that is my hope. Is this something that can be resolved with index_order in the XML file that defines the query?

[BSOD2600]

More of a scripting question, so moving.

Given an Indexed SNMP Query of data returned by something like dskTable or dskIOTable, am I correct that the index is not something static? In other words, after an snmpd restart or a host reboot the order of rows in these tables can change, correct?

Correct, but it ultimately depends on the device's implementation. For example on Windows, the Interface indexes don't change unless you add/remove network cards, yet occasionally processor indexes do change after MS updates / windows reboots.

I'm not really sure why the order matters, because if you have an index, you should be able to go straight to the specific device's info that you're after.

[sspyrison]

More of a scripting question, so moving.

I'm not really sure why the order matters, because if you have an index, you should be able to go straight to the specific device's info that you're after.

Well, it almost looks like the same problem described in the post prior to mine but not quite. I do have the data queries added with "Index Count Changed" as the Re-Index method.

My specific problem stemmed from starting with an SNMP Query XML file defining dskTable that did not contain an index_order. So, when I looked at the Data Sources they all had an Index Type of dskIndex (for example) and a value equal to the index presented in the snmptable (1, 2, 3, 12, etc)

Then, after a reboot on a Solaris host, for whatever reason those indexes shifted. My graphs all changed, and presented inaccurate data. For the sake of example, let's say before the reboot /usr/local had an index of 5 and /home had an index of 7. After reboot, /usr/local had an index of 7 and the graph shifted and started plotting the data for /home instead.

So, I changed the XML file to include

Code: Select all

        <index_order>dskPath:dskIndex</index_order>

and hoped that was the piece of the puzzle I was missing. I tested it a couple times, though, and wasn't convinced. With the XML file including index_order as above, the Data Source contains an Index Type of dskPath and a value of /usr/local (for example).

If I include an index_order as above and the Data Source reflects the dskPath (for example) as Index Value, is that all I need to do to maintain graph integrity if snmptable indexes change around post-reboot?

Apologies for the length of this, hope the question is clear, and many thanks for your assistance.

[sspyrison]

Well, it almost looks like the same problem described in the post prior to mine but not quite. I do have the data queries added with "Index Count Changed" as the Re-Index method.

Ok, well I may be guilty of jumping too far into this too soon. I took a few steps back and re-read the documentation. I think I understand this just fine, the index_order is a primary key to resolve the very problem I am experiencing.

In my case I don't think going with the "Index Count Changed" Re-Index method was the way to go. I think the host Uptime Goes Backwards method may be what I need. I had originally just followed the Howto and didn't read far enough along in the docs. Also, I hadn't read the CLI section so didn't realize there was a manual way to Re-Index.

Long story short, I was able to duplicate my "issue" with shifting graphs and then resolve it with a manual Re-Index, so that was nice to see. I'm proceeding to do my tests with the Uptime Re-Index method as that sounds more appropriate to the type of data I am working with in these few snmptables.