snmp query issue

Post general support questions here that do not specifically fall into the Linux or Windows categories.

Moderators: Developers, Moderators

Post Reply
colson
Posts: 9
Joined: Fri Apr 10, 2009 7:20 pm

snmp query issue

Post by colson »

I'm trying to create a query to monitor my UPS. I'd like to know what the oid_index should be for the following OIDs:

.1.3.6.1.4.1.13891.101.1.1.0 = STRING: "Mitsubishi"
.1.3.6.1.4.1.13891.101.1.2.0 = STRING: "UP2033C"
.1.3.6.1.4.1.13891.101.1.3.0 = STRING: "RJWBA11.10"
.1.3.6.1.4.1.13891.101.1.4.0 = STRING: "3.4.3-S"
.1.3.6.1.4.1.13891.101.1.5.0 = STRING: "10.64.59.220"
.1.3.6.1.4.1.13891.101.1.6.0 = ""
.1.3.6.1.4.1.13891.101.2.1.0 = INTEGER: batteryNormal(2)
.1.3.6.1.4.1.13891.101.2.2.0 = INTEGER: 0
.1.3.6.1.4.1.13891.101.2.3.0 = INTEGER: 63
.1.3.6.1.4.1.13891.101.2.4.0 = INTEGER: 0
.1.3.6.1.4.1.13891.101.2.5.0 = INTEGER: 4061
.1.3.6.1.4.1.13891.101.2.6.0 = INTEGER: 0
.1.3.6.1.4.1.13891.101.2.7.0 = INTEGER: 0
.1.3.6.1.4.1.13891.101.3.1.0 = Counter32: 0
.1.3.6.1.4.1.13891.101.3.2.0 = INTEGER: 3
.1.3.6.1.4.1.13891.101.3.3.1.1.1 = INTEGER: 0
.1.3.6.1.4.1.13891.101.3.3.1.1.2 = INTEGER: 0
.1.3.6.1.4.1.13891.101.3.3.1.1.3 = INTEGER: 0
.1.3.6.1.4.1.13891.101.3.3.1.2.1 = INTEGER: 600
.1.3.6.1.4.1.13891.101.3.3.1.2.2 = INTEGER: 0
.1.3.6.1.4.1.13891.101.3.3.1.2.3 = INTEGER: 0
.1.3.6.1.4.1.13891.101.3.3.1.3.1 = INTEGER: 1177
.1.3.6.1.4.1.13891.101.3.3.1.3.2 = INTEGER: 0
.1.3.6.1.4.1.13891.101.3.3.1.3.3 = INTEGER: 0
.1.3.6.1.4.1.13891.101.3.3.1.4.1 = INTEGER: 247
.1.3.6.1.4.1.13891.101.3.3.1.4.2 = INTEGER: 0
.1.3.6.1.4.1.13891.101.3.3.1.4.3 = INTEGER: 0
.1.3.6.1.4.1.13891.101.3.3.1.5.1 = INTEGER: 8784
.1.3.6.1.4.1.13891.101.3.3.1.5.2 = INTEGER: 0
.1.3.6.1.4.1.13891.101.3.3.1.5.3 = INTEGER: 0
.1.3.6.1.4.1.13891.101.4.1.0 = INTEGER: normal(3)
.1.3.6.1.4.1.13891.101.4.2.0 = INTEGER: 600
.1.3.6.1.4.1.13891.101.4.3.0 = INTEGER: 3
.1.3.6.1.4.1.13891.101.4.4.1.1.1 = INTEGER: 0
.1.3.6.1.4.1.13891.101.4.4.1.1.2 = INTEGER: 0
.1.3.6.1.4.1.13891.101.4.4.1.1.3 = INTEGER: 0
.1.3.6.1.4.1.13891.101.4.4.1.2.1 = INTEGER: 1203
.1.3.6.1.4.1.13891.101.4.4.1.2.2 = INTEGER: 0
.1.3.6.1.4.1.13891.101.4.4.1.2.3 = INTEGER: 0
.1.3.6.1.4.1.13891.101.4.4.1.3.1 = INTEGER: 439
.1.3.6.1.4.1.13891.101.4.4.1.3.2 = INTEGER: 0
.1.3.6.1.4.1.13891.101.4.4.1.3.3 = INTEGER: 0
.1.3.6.1.4.1.13891.101.4.4.1.4.1 = INTEGER: 8496
.1.3.6.1.4.1.13891.101.4.4.1.4.2 = INTEGER: 0
.1.3.6.1.4.1.13891.101.4.4.1.4.3 = INTEGER: 0
.1.3.6.1.4.1.13891.101.4.4.1.5.1 = INTEGER: 53
.1.3.6.1.4.1.13891.101.4.4.1.5.2 = INTEGER: 0
.1.3.6.1.4.1.13891.101.4.4.1.5.3 = INTEGER: 0
.1.3.6.1.4.1.13891.101.5.1.0 = INTEGER: 0
.1.3.6.1.4.1.13891.101.5.2.0 = INTEGER: 0
.1.3.6.1.4.1.13891.101.5.3.1.1.1 = INTEGER: 0
.1.3.6.1.4.1.13891.101.5.3.1.1.2 = INTEGER: 0
.1.3.6.1.4.1.13891.101.5.3.1.1.3 = INTEGER: 0
.1.3.6.1.4.1.13891.101.5.3.1.2.1 = INTEGER: 0
.1.3.6.1.4.1.13891.101.5.3.1.2.2 = INTEGER: 0
.1.3.6.1.4.1.13891.101.5.3.1.2.3 = INTEGER: 0
.1.3.6.1.4.1.13891.101.5.3.1.3.1 = INTEGER: 0
.1.3.6.1.4.1.13891.101.5.3.1.3.2 = INTEGER: 0
.1.3.6.1.4.1.13891.101.5.3.1.3.3 = INTEGER: 0
.1.3.6.1.4.1.13891.101.5.3.1.4.1 = INTEGER: 0
.1.3.6.1.4.1.13891.101.5.3.1.4.2 = INTEGER: 0
.1.3.6.1.4.1.13891.101.5.3.1.4.3 = INTEGER: 0


I'm not getting the data that I want. THe verbose query returns:

+ Running data query [17].
+ Found type = '3' [snmp query].
+ Found data query XML file at 'C:/cacti-0.8.7d/resource/snmp_queries/ups.xml'
+ XML file parsed ok.
+ Executing SNMP walk for list of indexes @ '.1.3.6.1.4.1.13891.101.1'
+ Index found at OID: 'enterprises.13891.101.1.1.0' value: 'Mitsubishi'
+ Index found at OID: 'enterprises.13891.101.1.2.0' value: 'UP2033C'
+ Index found at OID: 'enterprises.13891.101.1.3.0' value: 'RJWBA11.10'
+ Index found at OID: 'enterprises.13891.101.1.4.0' value: '3.4.3-S'
+ Index found at OID: 'enterprises.13891.101.1.5.0' value: '10.64.59.220'
+ Index found at OID: 'enterprises.13891.101.1.6.0' value: ''
+ Located input field 'ups' [walk]
+ Executing SNMP walk for data @ '.1.3.6.1.4.1.13891.101.1'
+ Found item [ups='Mitsubishi'] index: 0 [from value]
+ Found item [ups='UP2033C'] index: 0 [from value]
+ Found item [ups='RJWBA11.10'] index: 0 [from value]
+ Found item [ups='3.4.3-S'] index: 0 [from value]
+ Found item [ups='10.64.59.220'] index: 0 [from value]
+ Found item [ups=''] index: 0 [from value]
+ Found data query XML file at 'C:/cacti-0.8.7d/resource/snmp_queries/ups.xml'
+ Found data query XML file at 'C:/cacti-0.8.7d/resource/snmp_queries/ups.xml'
+ Found data query XML file at 'C:/cacti-0.8.7d/resource/snmp_queries/ups.xml'


and if I try to change the walk to .1.3.6.1.4.1.13891.101 (to get a broader walk) I get:

Notice: Undefined offset: 71 in C:\cacti-0.8.7d\lib\data_query.php on line 243

Notice: Undefined offset: 71 in C:\cacti-0.8.7d\lib\data_query.php on line 262

Notice: Undefined offset: 71 in C:\cacti-0.8.7d\lib\data_query.php on line 266
Warning: Cannot modify header information - headers already sent by (output started at C:\cacti-0.8.7d\lib\data_query.php:243) in C:\cacti-0.8.7d\host.php on line 79


How do I expand my query to get the OIDs I need further along the tree?

Thanks in advance.
User avatar
BSOD2600
Cacti Moderator
Posts: 12171
Joined: Sat May 08, 2004 12:44 pm
Location: USA

Post by BSOD2600 »

Having the MIB for that device would be useful to resolve the OID to their names. read the snmp xml template guide in http://docs.cacti.net/
colson
Posts: 9
Joined: Fri Apr 10, 2009 7:20 pm

Post by colson »

I've attached the MIB.

Thanks again for the assistance.
Attachments
Mitsubishi.txt
(38.98 KiB) Downloaded 141 times
User avatar
BSOD2600
Cacti Moderator
Posts: 12171
Joined: Sat May 08, 2004 12:44 pm
Location: USA

Post by BSOD2600 »

Great, so now use that mib file with that snmpwalk you posted so the OIDs are resolved to their textual names.

When you create your snmp xml file, you might want to read http://docs.cacti.net/howto:data_query_ ... _templates too.

Looks like .1.3.6.1.4.1.13891.101.3.2.0 might be the index count.
User avatar
TheWitness
Developer
Posts: 17007
Joined: Tue May 14, 2002 5:08 pm
Location: MI, USA
Contact:

Post by TheWitness »

Yea, what you were doing before would not work at all. It was not indexable data. Another good method is to walk the entire enterprise MIB using textual descriptions. When you remove the numeric and add the parsing from the MIB file, it will all start to make sense.

TheWitness
True understanding begins only when we realize how little we truly understand...

Life is an adventure, let yours begin with Cacti!

Author of dozens of Cacti plugins and customization's. Advocate of LAMP, MariaDB, IBM Spectrum LSF and the world of batch. Creator of IBM Spectrum RTM, author of quite a bit of unpublished work and most of Cacti's bugs.
_________________
Official Cacti Documentation
GitHub Repository with Supported Plugins
Percona Device Packages (no support)
Interesting Device Packages


For those wondering, I'm still here, but lost in the shadows. Yearning for less bugs. Who want's a Cacti 1.3/2.0? Streams anyone?
colson
Posts: 9
Joined: Fri Apr 10, 2009 7:20 pm

Post by colson »

It's slowly making sense, but I'm still unclear why .1.3.6.1.4.1.13891.101.3.2.0 would be the oid_index.
User avatar
nebj00la
Cacti User
Posts: 112
Joined: Fri Feb 17, 2006 9:02 pm
Location: Massachusetts, USA
Contact:

Post by nebj00la »

colson wrote:It's slowly making sense, but I'm still unclear why .1.3.6.1.4.1.13891.101.3.2.0 would be the oid_index.
What in particular are you looking to monitor? It seems to me there are multiple "indexes" in the walk you provided.
Thanks,
nebj00la
colson
Posts: 9
Joined: Fri Apr 10, 2009 7:20 pm

Post by colson »

I want to monitor the following:
<upsInputVoltage>
<name>Input Voltage</name>
<method>walk</method>
<source>value</source>
<direction>output</direction>
<oid>.1.3.6.1.4.1.13891.101.3.3.1.3.1</oid>
</upsInputVoltage>
<upsOutputVoltage>
<name>Output Voltage</name>
<method>walk</method>
<source>value</source>
<direction>output</direction>
<oid>.1.3.6.1.4.1.13891.101.4.4.1.2.1</oid>
</upsOutputVoltage>
<upsOutputPower>
<name>Output Power</name>
<method>walk</method>
<source>value</source>
<direction>output</direction>
<oid>.1.3.6.1.4.1.13891.101.4.4.1.4.1</oid>
</upsOutputPower>
<upsOutputPercentLoad>
<name>Output Percentage Load</name>
<method>walk</method>
<source>value</source>
<direction>output</direction>
<oid>.1.3.6.1.4.1.13891.101.4.4.1.5.1</oid>
</upsOutputPercentLoad>
<upsIdentManufacturer>
<name>Manufacturer</name>
<method>walk</method>
<source>value</source>
<direction>output</direction>
<oid>.1.3.6.1.4.1.13891.101.1.1.0</oid>

But that said, I can't figure out what the correct index should be.
User avatar
nebj00la
Cacti User
Posts: 112
Joined: Fri Feb 17, 2006 9:02 pm
Location: Massachusetts, USA
Contact:

Post by nebj00la »

colson wrote:I want to monitor the following:

<oid>.1.3.6.1.4.1.13891.101.3.3.1.3.1</oid>
<oid>.1.3.6.1.4.1.13891.101.4.4.1.2.1</oid>
<oid>.1.3.6.1.4.1.13891.101.4.4.1.4.1</oid>
<oid>.1.3.6.1.4.1.13891.101.4.4.1.5.1</oid>
<oid>.1.3.6.1.4.1.13891.101.1.1.0</oid>

But that said, I can't figure out what the correct index should be.
I'm no expert by any stretch of the word, but I think you are browsing three different indexes - 101.1, 101.3 and 101.4.

I don't know if it will work, but you can try .1.3.6.1.4.1.13891.101 as your index.
Thanks,
nebj00la
colson
Posts: 9
Joined: Fri Apr 10, 2009 7:20 pm

Post by colson »

Also, if I do the walk using the textual descriptions in the mib using the following index:

<oid_index>UPS-MIB::Tag</oid_index>

can I still run an OID/REGEX on the OID number or am I only able to parse text at this point?


Must.....unwind......brain......tangled.....knot.....

Thanks for the help!
User avatar
gandalf
Developer
Posts: 22383
Joined: Thu Dec 02, 2004 2:46 am
Location: Muenster, Germany
Contact:

Post by gandalf »

[personal opinion]I would prefer using ASN.1 numerical OIDs. They are more reliable than textual representation[/personal opinion] I indeed never tried REGEXP on textual representation
Reinhard
Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests