Re: [opennms-devel] trouble with SNMP on NetBotz device - SOLVED

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