I think that OID components can be any arbitrarily large non-negative integer (e.g.: 2617517747 is the troublesome one in this case), so we probably should be able to support them properly. Pat, do you want to open up a bug?
On Mon, 09 Jun 2008 16:21:56 -0500, "Patrick Landry" <[EMAIL PROTECTED]> said: > Tarus Balog <tarus <at> opennms.org> writes: > > > > > > > On Jun 5, 2008, at 12:41 PM, Patrick Landry wrote: > > > >> I am currently monitoring tempSensorValueIntF.1095346743 directly, for > >> instance, with this entry in datacollection-config.xml: > >> > >> <mibObj oid=".1.3.6.1.4.1.5528.100.4.1.1.1.9" instance="1095346743" > >> alias="netBotz2-temp" type="INTEGER" /> > >> > >> I assume that this works because the instance value happens to fit > >> into an integer. > >> > >> I would like to be able to monitor all of these sets of sensors using > >> Indexes rather than monitoring them directly. The leads me to the > >> problem of what MIB variable to use as an index. It seems that > >> tempSensorEntry.10 would be the correct Index variable for the > >> temperature sensors but how do I enter that into > >> datacollection-config.xml? > >> > >> My feeling is that this NetBotz MIB is broken. Is there any hope for > >> me? > > > > The new Netbotz mib is the suck (the version one stuff was amazing). I > > usually use generic indices to get this working. I can't remember > > which client I did this for recently (so I don't have an easy example) > > but by using the generics you can set the instance for everything > > (check the configs for the Net-SNMP disk stuff for an example). > > Given that Tarus had made it work I gave it another try and was able to > succeed. (Thanks Tarus.) I agree with Tarus that the new NetBotz MIB is > very poorly designed. > > Anyway, I went back and read "Collecting SNMP data from tables with > arbitrary indexes" again. When I read that the "name" attribute in the > resourceType definition "does not need to correlate to a MIB that > OpenNMS has knowledge of" that gave me some hope. I am attaching diffs > which show the changes I made to datacollection-config.xml and > snmp-graph.properties. Since the MIB groups the sensors by sensor type > rather than by the enclosure they are in the presentation of the graphs > in the OpenNMS WebUI is not very neat. But at least the data is there. > > Also, I am still seeing lines like this > > > 2008-06-09 16:18:12,062 DEBUG [CollectdScheduler-50 Pool-fiber0] > > OneToOnePersister: Storing attribute > > node[22].nb2DewIndex[-1677449549].netBotz2-dew-enc > > [.1.3.6.1.4.1.5528.100.4.1.3.1.5] = nbHawkEnc_1 > > in collectd.log. Note that the index here is negative (-1677449549). But > the index in the MIB is not > > > NETBOTZV2-MIB::dewPointSensorEncId.2617517747 = STRING: nbHawkEnc_1 > > So OpenNMS is coping with the fact that the MIB index is a larger value > than will fit in an integer. I assumed this would cause problems. > Apparently it does not. (A happy accident?) > > Hopefully the next poor soul who has to deal with this > device will find this in the archives. > > -- > patrick > > Patrick Landry > Asst. V.P., Information Technology > University of Louisiana at Lafayette > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Please read the OpenNMS Mailing List FAQ: http://www.opennms.org/index.php/Mailing_List_FAQ opennms-devel mailing list To *unsubscribe* or change your subscription options, see the bottom of this page: https://lists.sourceforge.net/lists/listinfo/opennms-devel
