be more flexable with oid/regex output in XML files

Anything that you think should be in Cacti.

Moderators: Developers, Moderators

Post Reply
Ragnar
Posts: 5
Joined: Thu Aug 04, 2005 10:33 am

Post by Ragnar »

TheWitness wrote:Does anyone have a patch? It won't make it into Saturday's release, but...

TheWitness
This only supports output, not input fields, but input fields generally don't have poorly formed mibs, this patch adds an oid_suffix tag to the xml. patched against 0.8.7a

Code: Select all

diff -rup cacti.0.8.7a/lib/utility.php cacti/lib/utility.php
--- cacti.0.8.7a/lib/utility.php        2007-12-11 10:54:13.000000000 -0500
+++ cacti/lib/utility.php       2007-12-11 11:31:07.000000000 -0500
@@ -147,6 +147,9 @@ function update_poller_cache($local_data
                        foreach ($outputs as $output) {
                                if (isset($snmp_queries["fields"]{$output["snmp_field_name"]}["oid"])) {
                                        $oid = $snmp_queries["fields"]{$output["snmp_field_name"]}["oid"] . "." . $data_source["snmp_index"];
+                                       if (isset($snmp_queries["fields"]{$output["snmp_field_name"]}["oid_suffix"])) {
+                                               $oid .= "." . $snmp_queries["fields"]{$output["snmp_field_name"]}["oid_suffix"];
+                                       }
                                }
 
                                if (!empty($oid)) {
Top
User avatar
gandalf
Developer
Posts: 22383
Joined: Thu Dec 02, 2004 2:46 am
Location: Muenster, Germany
Contact:
Contact gandalf

Post by gandalf »

Please show us an XML file which uses this new feature.
Reinhard
Top
User avatar
TheWitness
Developer
Posts: 17047
Joined: Tue May 14, 2002 5:08 pm
Location: MI, USA
Contact:
Contact TheWitness

Post by TheWitness »

Once this is well documented, if viable, please direct to open a feature request with the relevant information.

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?
Top
User avatar
gandalf
Developer
Posts: 22383
Joined: Thu Dec 02, 2004 2:46 am
Location: Muenster, Germany
Contact:
Contact gandalf

Post by gandalf »

Oh, I volunteer for this, including docs, for sure. But I first need to understand better.
Reinhard
Top
steagu
Posts: 37
Joined: Thu Nov 15, 2007 12:15 pm
Location: Manchester, United Kingdom

Post by steagu »

Just my 2 cents to this feature request thread...

I'm trying to graph Quality of Service (QoS) statistics on a Cisco Device. The SNMP walk for the particular OID i'm graphing (QOSDropPackets in this case) shows the following

SNMPv2-SMI::enterprises.9.9.189.1.3.2.1.7.10101.1.1 = Counter64: 0
SNMPv2-SMI::enterprises.9.9.189.1.3.2.1.7.10101.2.1 = Counter64: 0
SNMPv2-SMI::enterprises.9.9.189.1.3.2.1.7.10102.1.1 = Counter64: 0
SNMPv2-SMI::enterprises.9.9.189.1.3.2.1.7.10102.2.1 = Counter64: 185716
SNMPv2-SMI::enterprises.9.9.189.1.3.2.1.7.10103.1.1 = Counter64: 0
SNMPv2-SMI::enterprises.9.9.189.1.3.2.1.7.10103.2.1 = Counter64: 127041
SNMPv2-SMI::enterprises.9.9.189.1.3.2.1.7.10104.1.1 = Counter64: 0
SNMPv2-SMI::enterprises.9.9.189.1.3.2.1.7.10104.2.1 = Counter64: 0
SNMPv2-SMI::enterprises.9.9.189.1.3.2.1.7.10105.1.1 = Counter64: 0




And my index shows:

+ Found item [ifIndex='10101'] index: 10101 [from value]
+ Found item [ifIndex='10102'] index: 10102 [from value]
+ Found item [ifIndex='10103'] index: 10103 [from value]
+ Found item [ifIndex='10104'] index: 10104 [from value]
+ Found item [ifIndex='10105'] index: 10105 [from value]
+ Found item [ifIndex='10106'] index: 10106 [from value]
+ Found item [ifIndex='10107'] index: 10107 [from value]
+ Found item [ifIndex='10108'] index: 10108 [from value]
+ Found item [ifIndex='10109'] index: 10109 [from value]

This is from another thread I had open asking for help in graphing this information at http://forums.cacti.net/viewtopic.php?t=24337
Top
Ragnar
Posts: 5
Joined: Thu Aug 04, 2005 10:33 am

Post by Ragnar »

gandalf wrote:Please show us an XML file which uses this new feature.
Reinhard

Code: Select all

<interface>
        <name>Get MetaSwitch ISUP Signalling Destinations</name>
        <index_order_type>numeric</index_order_type>
        <oid_index>.1.2.826.0.1.1578918.6.1218.1.5</oid_index>

        <oid_index_parse>OID/REGEXP:.*\.1578918\.6\.[0-9]{1,4}\.1\.[0-9]{1,4}\.(.*)$</oid_index_parse>

        <fields>
                <msDN>
                        <name>DN</name>
                        <method>walk</method>
                        <source>value</source>
                        <direction>input</direction>
                        <oid>.1.2.826.0.1.1578918.6.1218.1.5</oid>
                </msDN>
                <msStatus>
                        <name>Status</name>
                        <method>walk</method>
                        <source>value</source>
                        <direction>input</direction>
                        <oid>.1.2.826.0.1.1578918.6.1218.1.52</oid>
                </msStatus>
                <msChansCfgdHighWaterMark>
                        <name>ChansCfgdHighWaterMark</name>
                        <method>walk</method>
                        <source>value</source>
                        <direction>output</direction>
                        <oid>.1.2.826.0.1.1578918.6.786.1.9</oid>
                        <oid_suffix>2</oid_suffix>
                </msChansCfgdHighWaterMark>
                <msChansInUseCallsHighWaterMark>
                        <name>ChansInUseCallsHighWaterMark</name>
                        <method>walk</method>
                        <source>value</source>
                        <direction>output</direction>
                        <oid>.1.2.826.0.1.1578918.6.786.1.13</oid>
                        <oid_suffix>2</oid_suffix>
                </msChansInUseCallsHighWaterMark>
                <msChansInUseOrigCallsHighWaterMark>
                        <name>ChansInUseOrigCallsHighWaterMark</name>
                        <method>walk</method>
                        <source>value</source>
                        <direction>output</direction>
                        <oid>.1.2.826.0.1.1578918.6.786.1.17</oid>
                        <oid_suffix>2</oid_suffix>
                </msChansInUseOrigCallsHighWaterMark>
                <msChansInUseTermCallsHighWaterMark>
                        <name>ChansInUseTermCallsHighWaterMark</name>
                        <method>walk</method>
                        <source>value</source>
                        <direction>output</direction>
                        <oid>.1.2.826.0.1.1578918.6.786.1.21</oid>
                        <oid_suffix>2</oid_suffix>
                </msChansInUseTermCallsHighWaterMark>
                <msCallUsageOrigingCalls>
                        <name>CallUsageOrigingCalls</name>
                        <method>walk</method>
                        <source>value</source>
                        <direction>output</direction>
                        <oid>.1.2.826.0.1.1578918.6.786.1.36</oid>
                        <oid_suffix>2</oid_suffix>
                </msCallUsageOrigingCalls>
                <msCntTermCallAttsAnswrd>
                        <name>CntTermCallAttsAnswrd</name>
                        <method>walk</method>
                        <source>value</source>
                        <direction>output</direction>
                        <oid>.1.2.826.0.1.1578918.6.786.1.41</oid>
                        <oid_suffix>2</oid_suffix>
                </msCntTermCallAttsAnswrd>
                <msCntTermCallAttsRejAsBusy>
                        <name>CntTermCallAttsRejAsBusy</name>
                        <method>walk</method>
                        <source>value</source>
                        <direction>output</direction>
                        <oid>.1.2.826.0.1.1578918.6.786.1.42</oid>
                        <oid_suffix>2</oid_suffix>
                </msCntTermCallAttsRejAsBusy>
                <msCntTermCallAttsNotAnswrd>
                        <name>CntTermCallAttsNotAnswrd</name>
                        <method>walk</method>
                        <source>value</source>
                        <direction>output</direction>
                        <oid>.1.2.826.0.1.1578918.6.786.1.43</oid>
                        <oid_suffix>2</oid_suffix>
                </msCntTermCallAttsNotAnswrd>
        </fields>
</interface>
the problem this solves, is oids formed like:

Code: Select all

# snmpbulkwalk -v2c -cpublic x.x.x.x .1.2.826.0.1.1578918.6.786.1.13
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.48.50.51.52.49.54.1 = Gauge32: 0
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.48.50.51.52.49.54.2 = Gauge32: 0
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.48.50.51.52.49.54.3 = Gauge32: 0
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.48.50.51.52.49.54.4 = Gauge32: 0
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.48.50.51.52.49.54.5 = Gauge32: 0
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.48.50.51.52.49.54.6 = Gauge32: 0
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.48.50.51.52.49.54.7 = Gauge32: 0
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.48.50.51.52.49.54.8 = Gauge32: 0
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.52.56.53.54.57.49.1 = Gauge32: 0
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.52.56.53.54.57.49.2 = Gauge32: 0
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.52.56.53.54.57.49.3 = Gauge32: 0
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.52.56.53.54.57.49.4 = Gauge32: 0
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.52.56.53.54.57.49.5 = Gauge32: 0
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.52.56.53.54.57.49.6 = Gauge32: 1
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.52.56.53.54.57.49.7 = Gauge32: 1
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.52.56.53.54.57.49.8 = Gauge32: 1
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.53.52.56.52.56.56.1 = Gauge32: 1
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.53.52.56.52.56.56.2 = Gauge32: 1
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.53.52.56.52.56.56.3 = Gauge32: 1
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.53.52.56.52.56.56.4 = Gauge32: 3
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.53.52.56.52.56.56.5 = Gauge32: 3
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.53.52.56.52.56.56.6 = Gauge32: 3
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.53.52.56.52.56.56.7 = Gauge32: 3
iso.2.826.0.1.1578918.6.786.1.13.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.53.52.56.52.56.56.8 = Gauge32: 1
where they have a trailing suffix after the index (in this case standing for cur 5min = 1, prev 5min = 2, cur 15 = 3, prev 15 = 4, etc)

The index/input OIDs on the other hand are well formed:

Code: Select all

# snmpbulkwalk -v2c -cpublic x.x.x.x .1.2.826.0.1.1578918.6.1218.1.5
iso.2.826.0.1.1578918.6.1218.1.5.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.48.50.51.52.49.54 = STRING: "xxx2023416"
iso.2.826.0.1.1578918.6.1218.1.5.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.52.56.53.54.57.49 = STRING: "xxx2485691"
iso.2.826.0.1.1578918.6.1218.1.5.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.53.52.56.52.56.56 = STRING: "xxx2548488"
iso.2.826.0.1.1578918.6.1218.1.5.1.7.100.101.102.97.117.108.116.1.10.51.49.55.50.54.52.50.54.48.48 = STRING: "xxx2642600"
Top
User avatar
gandalf
Developer
Posts: 22383
Joined: Thu Dec 02, 2004 2:46 am
Location: Muenster, Germany
Contact:
Contact gandalf

Post by gandalf »

Fine, I already supposed it would work this way. Will try to implement it for next release
Reinhard
Top
Syngress
Posts: 26
Joined: Tue Apr 24, 2007 9:17 am

Post by Syngress »

I asked earlier (In this thread) about being about to walk OID's that use a suffix, and having seen the above 'patch' am wondering if this will solve my issue :)

The problem I have is when I snmpwalk the OID I get the following :-

snmpwalk ps-1.BHM1 -c yyyyy .1.3.6.1.4.1.1991.1.1.2.11.1.1.4
enterprises.1991.1.1.2.11.1.1.4.1.1.1 = Gauge32: 1
enterprises.1991.1.1.2.11.1.1.4.1.1.5 = Gauge32: 1
enterprises.1991.1.1.2.11.1.1.4.1.1.60 = Gauge32: 1
enterprises.1991.1.1.2.11.1.1.4.1.1.300 = Gauge32: 1
enterprises.1991.1.1.2.11.1.1.4.5.1.1 = Gauge32: 1
enterprises.1991.1.1.2.11.1.1.4.5.1.5 = Gauge32: 1
enterprises.1991.1.1.2.11.1.1.4.5.1.60 = Gauge32: 1
enterprises.1991.1.1.2.11.1.1.4.5.1.300 = Gauge32: 1
enterprises.1991.1.1.2.11.1.1.4.9.1.1 = Gauge32: 0
enterprises.1991.1.1.2.11.1.1.4.9.1.5 = Gauge32: 0
enterprises.1991.1.1.2.11.1.1.4.9.1.60 = Gauge32: 0
enterprises.1991.1.1.2.11.1.1.4.9.1.300 = Gauge32: 0
enterprises.1991.1.1.2.11.1.1.4.10.1.1 = Gauge32: 0
enterprises.1991.1.1.2.11.1.1.4.10.1.5 = Gauge32: 0
enterprises.1991.1.1.2.11.1.1.4.10.1.60 = Gauge32: 0
enterprises.1991.1.1.2.11.1.1.4.10.1.300 = Gauge32: 0

Now the index values in this case are the 1,5,9 &10, but these are then followed by a .1 and then the .1,.5,.60 &.300 represent 1,5,60 or 300 second usage.....

Is there a way of using the above 'patch' and the <oid_suffix> that I can get this to work at last ?

Thanks....

Mike
Top
cbscpe
Posts: 15
Joined: Fri Apr 11, 2008 1:07 am
Location: Switzerland

Post by cbscpe »

I had the same problem as many in this thread. First I needed a more flexible use of REGEX and second my Indexes are not at the end of the OID.

I opened a feature request and also wrote a patch to allow for several enhancements regarding the issues discussed in this thread.

See the following discussion


http://forums.cacti.net/about26851.html


I added the following functions to SNMP Query Indexed

1. Added a new field <oid_index_filter> which accepts a REGEX to filter only those OID that effectively match (<oid_index_parse> only parses the OIDs but keeps all records returned by the SNMPWALK even if the REGEX does not match). This is useful to filter OIDs to keep only one with the interesting Index.

2. Added a new field <index_parse> which can be used in input and output fields. The result is that instead of joining the content of <oid> and the index it accepts a REGEX in <index_parse> which is then applied to the index and uses <oid> as the replacement string. You can use as many groups you want in the REGEX and using the \1, .. \9 to insert the matched strings at any place in the <oid>, not only the end. My patch has only support for the get method and not for the walk method.

3. Added a new field <string> which can be used in to create an arbitrary text.

The code still uses ereg_replace, I have not really seen any advantage of using preg_replace although it could be done.

Currently we are using these features to pull all G.SHDSL Counters (Near and Far end) with one query. Patches required are attached here.


http://bugs.cacti.net/view.php?id=1225


Peter
Top
Post Reply

Return to “Feature Requests”

Who is online

Users browsing this forum: No registered users and 3 guests