Ad Widget

**ploeger** · 10-01-2008, 10:18

Hi Raymond!

Whoooops.. Thanks. I've updated the script to 1.1 in the wiki now.

Kind regards,
Dennis

**croft01** · 27-02-2008, 22:15

usage.... i'm stuck....

Hi this looks great if i've understood everything but I'm having a bit of trouble getting this to work...

I've got Zabbix version 1.4.4

I'm just not sure of the syntax when running the zload_snmp script..

I've got a MIB file called interceptor.mib which I would love to get converted to an xml file.

Not sure if you need the host name...?

Is there any chance of a little help...?

Thanks in advance

Attached Files

interseptor.zip (5.6 KB, 453 views)

**ploeger** · 28-02-2008, 09:45

Hi!

It seems, like you've got it all wrong with the mib-stuff. MIBs are only there to "convert" your snmp-data you receive from a host into a human readable form (that's very simple speaking, I know). What you have to do is the following:

* Copy your mib into your system's mib-directory. On Debian with an installed package "libsnmp-base" it is under /usr/share/snmp/mibs.
* Run zload_snmpwalk with the following arguments:
* -x (export to xml)
* -m ALL (load all mibs under /usr/share/snmp/mibs)
* -v 1 (snmp version 1)
* public (the SNMP-community configured on your host)
* myTemplate (name of the Zabbix-template you'd like to create)
* my.hostname.com (the name of your SNMP-aware host)
* .1.3.6.1.4 (the starting OID from where you'd like to scan the host)

So the command is:

zload_snmpwalk.pl -x -m ALL -v 1 public myTemplate my.hostname.com .1.3.6.1.4

If you don't get the terms "SNMP-community" and "OID", you should probably freshen up your knowledge about SNMP first.

HTH.

Regards,
Dennis

**croft01** · 28-02-2008, 17:47

All Sorted

Thanks for getting back to me....

Ahh I now understand, ok I've also read a bit about it as well

All sorted and it's up and running...

Many thanks for your help.

**rrr** · 11-04-2008, 04:05

When I run the script I get for some (none numerical indexes) oids the following output:

Code:

04/10/2008 06:32:11.115: Unknown Object Identifier (Index out of range: 04/10/2008 06:32:11 (staIproEstabTim))
No log handling enabled - turning on stderr logging
.iso.org.dod.internet.private.enterprises.lancom-systems.adsl-systems.iad-annex-b.lancom-1722.sta.staIpro.staIproRip.staIproRipLanTable.staIproRipLanEntry.staIproRipLanNetw.INTRANET: Unknown Object Identifier (Index out of range: INTRANET (staIproRipLanNetw))
No log handling enabled - turning on stderr logging

How can I solve this problem?

**ploeger** · 15-04-2008, 11:08

Hi!

That...

Originally posted by rrr

Code:

04/10/2008 06:32:11.115: Unknown Object Identifier (Index out of range: 04/10/2008 06:32:11 (staIproEstabTim))
No log handling enabled - turning on stderr logging
.iso.org.dod.internet.private.enterprises.lancom-systems.adsl-systems.iad-annex-b.lancom-1722.sta.staIpro.staIproRip.staIproRipLanTable.staIproRipLanEntry.staIproRipLanNetw.INTRANET: Unknown Object Identifier (Index out of range: INTRANET (staIproRipLanNetw))
No log handling enabled - turning on stderr logging

... looks like an error in your MIB-File. This happens A LOT! Some vendors just doesn't seem to understand how to properly write a MIB-file.

So, sorry. Can't help you there. However, the error output shouldn't be in the XML-output you get (Don't reroute stderr to stdout like 2>&1 when you're starting the script.). If you don't get XML-output at all, this MIB-error seems to stop the whole processing. Perhaps you should get a new MIB-file or delete the file that causes this error.

Sorry.

Regards
Dennis

**rthomson** · 04-06-2008, 22:15

Hi,

First of all, I'd like to thank the author for this little gem! It's a great tool for loading up Zabbix with SNMP items.

I'm using the zload_snmpwalk.pl script to load up Zabbix with templates for several SNMP devices. I noticed that with a few of my devices, the zload_snmpwalk.pl script will create the names of some item keys as simply the last two numbers of the OID instead of the actual string description from the MIB.

I believe (although I haven't tested any changes to be sure) this is due to the following function:

Code:

sub get_zabbix_description
{

        my $raw_oid = shift(@_);
        my $pos;

        # Step back 2 positions for a description string and key

        $pos = length($raw_oid);

        for (my $i=0; $i<$zabbix_right;$i++) {

                $pos = rindex($raw_oid,'.', $pos - 1);

        }

        return substr($raw_oid, $pos + 1);
}

The assumption that we need to step back two positions to get the description string and key may not be correct in all cases.

I'll provide an example. I have a Xerox DocuPrint N2125 that I can snmpwalk and I get the following result:

(command: snmpwalk -v1 -m ALL -Oa -c community printer.name.dns .1.3.6.1.2.1.43.18)

Code:

Printer-MIB::prtAlertSeverityLevel.1.221 = INTEGER: warning(4)
Printer-MIB::prtAlertTrainingLevel.1.221 = INTEGER: untrained(3)
Printer-MIB::prtAlertGroup.1.221 = INTEGER: generalPrinter(5)
Printer-MIB::prtAlertGroupIndex.1.221 = INTEGER: 1
Printer-MIB::prtAlertLocation.1.221 = INTEGER: 3
Printer-MIB::prtAlertCode.1.221 = INTEGER: subunitPowerSaver(23)
Printer-MIB::prtAlertDescription.1.221 = STRING: "Power Saver On"
Printer-MIB::prtAlertTime.1.221 = Timeticks: (637316646) 73 days, 18:19:26.46

And the results returned from zload_snmpwalk.pl:

(command: ./zload_snmpwalk.pl -m ALL -x -v 1 community Template_Xerox_DocuPrintN2125 printer.name.dns .1.3.6.1.2.1.43.18)

Code:

<zabbix_export version="1.0" date="04.06.08" time="13:00">
        <hosts>
                <host name="Template_Xerox_DocuPrintN2125">
                        <status>3</status>
                        <item type="1" key="1.221" value_type="0">
                                <description>1.221</description>
                                <delay>60</delay>
                                <history>7</history>
                                <trends>365</trends>
                                <snmp_community>public</snmp_community>
                                <snmp_oid>.1.3.6.1.2.1.43.18.1.1.2.1.221</snmp_oid>
                                <snmp_port>161</snmp_port>
                        </item>
                        <item type="1" key="1.221" value_type="0">
                                <description>1.221</description>
                                <delay>60</delay>
                                <history>7</history>
                                <trends>365</trends>
                                <snmp_community>public</snmp_community>
                                <snmp_oid>.1.3.6.1.2.1.43.18.1.1.3.1.221</snmp_oid>
                                <snmp_port>161</snmp_port>
                        </item>
                        <item type="1" key="1.221" value_type="0">
                                <description>1.221</description>
                                <delay>60</delay>
                                <history>7</history>
                                <trends>365</trends>
                                <snmp_community>public</snmp_community>
                                <snmp_oid>.1.3.6.1.2.1.43.18.1.1.4.1.221</snmp_oid>
                                <snmp_port>161</snmp_port>
                        </item>
                        <item type="1" key="1.221" value_type="0">
                                <description>1.221</description>
                                <delay>60</delay>
                                <history>7</history>
                                <trends>365</trends>
                                <snmp_community>public</snmp_community>
                                <snmp_oid>.1.3.6.1.2.1.43.18.1.1.5.1.221</snmp_oid>
                                <snmp_port>161</snmp_port>
                        </item>
                        <item type="1" key="1.221" value_type="0">
                                <description>1.221</description>
                                <delay>60</delay>
                                <history>7</history>
                                <trends>365</trends>
                                <snmp_community>public</snmp_community>
                                <snmp_oid>.1.3.6.1.2.1.43.18.1.1.6.1.221</snmp_oid>
                                <snmp_port>161</snmp_port>
                        </item>
                        <item type="1" key="1.221" value_type="0">
                                <description>1.221</description>
                                <delay>60</delay>
                                <history>7</history>
                                <trends>365</trends>
                                <snmp_community>public</snmp_community>
                                <snmp_oid>.1.3.6.1.2.1.43.18.1.1.7.1.221</snmp_oid>
                                <snmp_port>161</snmp_port>
                        </item>
                        <item type="1" key="1.221" value_type="1">
                                <description>1.221</description>
                                <delay>60</delay>
                                <history>7</history>
                                <trends>365</trends>
                                <snmp_community>public</snmp_community>
                                <snmp_oid>.1.3.6.1.2.1.43.18.1.1.8.1.221</snmp_oid>
                                <snmp_port>161</snmp_port>
                        </item>
                        <item type="1" key="1.221" value_type="0">
                                <description>1.221</description>
                                <delay>60</delay>
                                <history>7</history>
                                <trends>365</trends>
                                <snmp_community>public</snmp_community>
                                <snmp_oid>.1.3.6.1.2.1.43.18.1.1.9.1.221</snmp_oid>
                                <snmp_port>161</snmp_port>
                        </item>
                </host>
        </hosts>
</zabbix_export>

As you can see, the values for "key" in the XML only represent the last two parts of the OID, which in this case happen to be numeric and not include any of the text description from the MIB. This is why I suspect the "get_zabbix_description" subroutine and it's assumption of going back two steps to get the string description.

I also had this happen for some keys while I was using zload_snmpwalk.pl for my IBM BladeCenter but there isn't anything new to show by example with that case so I won't bother.

Now, I can't immediately offer any solution as I am certainly no expert or authority on SNMP and how to effectively make a judgement on when or how the script should decide how many steps back it should take for a specific OID.

I believe I can just edit the script to step back a different number of steps for the specific OIDs (and then run it against just the OIDs that need more steps back) but I am certain that there can be a more elegant solution.

Any thoughts?

Once I work my way around this issue, I'll be posting some of the templates I've generated, most of which will be of questionable value to others since it's so easy to create them with zload_snmpwalk.pl, but hey, I figure after benefiting so much from community contributions, I might as well contribute back anything I can.

**ploeger** · 05-06-2008, 08:48

Hi rthomson!

This sadly cannot be done "automagically", because it depends on the number and complexity of items under a specific information.

In your example you have the information "prtAlertGroup" for several objects in your printer. So you have a object "1" with a subobject "221" and perhaps your printer or another printer of the same vendor has another subobject "222" or even another object "2" or something. According to my knowledge, this information cannot be found somewhere. (If it can, please tell me!)

So zload_snmpwalk has another argument, which you probably overlooked:

-R num Use num indexes from the right as the description (default: 2)

So per default the script uses the two last objects it gets from the mib (which would be 1.221 in your example). If you set this to 3, you'd get the last three, which would include "prtAlertGroup". So your items will be named "prtAlertGroup.1.221".

BTW: What "1.221" really is can only be told by the vendor. Hope you're not dealing with Ricoh-printers out there :-(

Hth.

Regards
Dennis

**rthomson** · 06-06-2008, 01:30

Thanks for replying.

I thought I spent enough time digging through information to find out whether this was a "known issue" or was already solved or what not... but it seems I missed the most obvious place to check, the usage information/documentation!

**lwickline** · 09-09-2008, 00:46

Getting an error with the latest version. can anyone help with why?

./zload_snmpwalk -d zabbix -u root -P password comunity 10069 file
.DBD::mysql::st execute failed: Column 'type' cannot be null at ./zload_snmpwalk line 314, <SWALK> line 1.
Insert Failure: DBI::st=HASH(0x8819c0)->strerror

**ploeger** · 01-10-2008, 09:52

Ah... I haven't looked at the database-part of the import script, I just worked out the XML-part.

But I would stick to the XML-Solution, lwickline. Read the other posts of this thread to get the right arguments.

Thanks.

Kind regards,
Dennis

**riegersteve** · 17-01-2009, 02:42

Originally posted by lwickline

Getting an error with the latest version. can anyone help with why?

got the same error

**matteb2** · 09-07-2010, 12:51

up to date script?

Hi All,

I was just wondering if it's available somewhere an up to date version of this script...

Thank you ,

**canepan** · 09-09-2010, 09:24

Updated version

I think you can find it here:
http://www.zabbix.com/wiki/howto/mon...zload_snmpwalk
I even posted an updated version (in comments)

**matteb2** · 10-09-2010, 18:13

thank you canepan!

Kind regards,

Ad Widget

Tool for bulkloading a template with snmpwalk data

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment