|
|
| Author |
Message |
Ragnar
Joined: 04 Aug 2005 Posts: 5
|
Posted: Wed Dec 12, 2007 12:13 pm Post subject: |
|
|
| 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: |
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)) {
|
|
|
| Back to top |
|
 |
gandalf Developer
Joined: 02 Dec 2004 Posts: 11294 Location: Muenster, Germany
|
Posted: Sat Dec 15, 2007 1:35 pm Post subject: |
|
|
Please show us an XML file which uses this new feature.
Reinhard |
|
| Back to top |
|
 |
TheWitness Developer
Joined: 14 May 2002 Posts: 9255 Location: MI, USA
|
Posted: Sat Dec 15, 2007 2:35 pm Post subject: |
|
|
Once this is well documented, if viable, please direct to open a feature request with the relevant information.
TheWitness |
|
| Back to top |
|
 |
gandalf Developer
Joined: 02 Dec 2004 Posts: 11294 Location: Muenster, Germany
|
Posted: Sat Dec 15, 2007 2:51 pm Post subject: |
|
|
Oh, I volunteer for this, including docs, for sure. But I first need to understand better.
Reinhard |
|
| Back to top |
|
 |
steagu
Joined: 15 Nov 2007 Posts: 37 Location: Manchester, United Kingdom
|
Posted: Mon Dec 17, 2007 7:38 am Post subject: |
|
|
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 |
|
| Back to top |
|
 |
Ragnar
Joined: 04 Aug 2005 Posts: 5
|
Posted: Mon Dec 17, 2007 3:25 pm Post subject: |
|
|
| gandalf wrote: | Please show us an XML file which uses this new feature.
Reinhard |
| Code: |
<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: |
# 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: |
# 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"
|
|
|
| Back to top |
|
 |
gandalf Developer
Joined: 02 Dec 2004 Posts: 11294 Location: Muenster, Germany
|
Posted: Wed Dec 19, 2007 3:33 pm Post subject: |
|
|
Fine, I already supposed it would work this way. Will try to implement it for next release
Reinhard |
|
| Back to top |
|
 |
Syngress
Joined: 24 Apr 2007 Posts: 13
|
Posted: Tue Jan 29, 2008 10:26 am Post subject: |
|
|
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 |
|
| Back to top |
|
 |
cbscpe
Joined: 11 Apr 2008 Posts: 15 Location: Switzerland
|
Posted: Thu May 01, 2008 1:51 pm Post subject: |
|
|
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
[url]
http://forums.cacti.net/about26851.html
[/url]
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.
[url]
http://bugs.cacti.net/view.php?id=1225
[/url]
Peter |
|
| Back to top |
|
 |
|