Re: [Devmon] T or even P bits speed output in 'home made'-cisco-n7000 switch template

[Peter W. <pet...@gm...>]

Hi Wim,

Thanks again for your quick response.

There is one network object that is queried by two vm's (xymon-dev,
xymon-acc) and one hw box.
The two vm's are preps for a new xymon server with the latest and greatest;
the hw box is our current xymon prod box.

Only the hw box works as expected. The two vm's are similar build and
produces spikes at different times.

What the three hosts have in common is the Xymon-html-output for this
network device. Which shows normal output. The hidden devmon code is also
normal. A batch job that queries the network device also produces normal
output (your previous suggestion, as I recall).

So I have rrd files that when I look into these files show absurd values.
But that could be perhaps an error in the processing of the hidden devmon
code? Or an rrd anomaly? Or just my own 'unknown error'?

What I just did:
I tried to minimize the shown devices. So I managed to do so, by re-using a
field shown (Errors in) from the If_Err-test. But underneath all the
64-bits interfaces are queried, so devmon output is still shown for all the
devices.

<!--DEVMON RRD: if_load 0 0DS:ds0:COUNTER:600:0:U
DS:ds1:COUNTER:600:0:Umgmt0 8879632404:16047447934loopback0
15094564810:145416650Ethernet3_1 5145707654:5008405830Ethernet3_2
275179849444513:598883108402034Ethernet3_3
1100302946652053:951076190448071Ethernet3_4
51407929508676:69081629766292Ethernet3_5
823099309481:5352820011173Ethernet3_6 199285632:199285632Ethernet3_7
199285632:199285632Ethernet3_8 199285632:199285632Ethernet4_1
3118632864693475:491943590772051Ethernet4_2
414769440784827:649329384941863Ethernet4_3
103430757126278:415216974406768Ethernet4_4
156480646041793:681504646556060Ethernet4_5
299330487390116:1361606088437009Ethernet4_6
45595170267863:313429801053492Ethernet4_7
199285632:199285632Ethernet4_8 199285632:199285632Ethernet3_1
0:0Ethernet3_2 0:0Ethernet3_3 0:0Ethernet4_1 0:0Ethernet4_2
0:0Ethernet4_3 0:0Ethernet4_4 0:0Ethernet4_5 0:0Ethernet4_6
0:0Ethernet3_4 0:0Ethernet3_5 0:0-->

And now I will try your suggestion using exceptions file:

[root@uhu-o if_load]# cat exceptions

#ifName : alarm  : .+

ifName : ignore : Nu.+|Vl.+|VLAN.+

ifHCInOctets : only : 0
Unfortunately the output remains the same as above (for all counters).
Perhaps I'm missing something here...?

regards,
Peter

2017-01-13 15:31 GMT+01:00 W.J.M. Nelis <Wim...@nl...>:

> Hello Peter,
>
> > Until now I checked and reproduced the error on two similar RHEL6
> servers:
> >
> > -both vm's
> > -Xymon version *Xymon 4.3.27-4.el6.terabithia
> > <http://xymon.sourceforge.net/>*
> >
> > Perl v5.10.1
> >
> > net-snmp-libs-5.5-57.el6_8.1.x86_64
> > net-snmp-5.5-57.el6_8.1.x86_64
> > net-snmp-utils-5.5-57.el6_8.1.x86_64
> > perl-SNMP_Session-1.12-4.el6.noarch
> > rrdtool-1.5.5-1.1.el6.x86_64
> >
> > -devmon: I tried two versions. One old version  $Id: README 96 2008-12-07
> > 20:01:21Z buchanmilne $ and the newest from svn://
> > svn.code.sf.net/p/devmon/code/trunk but the behaviour is the same for
> both.
> > Spikey to Tb of Pb :-(
> >
> > A script that queries the device showed no problem. So it suspect the
> > problem to be somewhere near the integration in Xymon and rrdtool, I
> think.
> >
> Do both vm's have a similar list of interfaces, that is with interfaces
> which occur two times in the list? Are those interfaces also visible in
> twofold in the CLI?
>
> My guess is that the two occurrences of an interface causes those spikes.
> If there is no other way to suppress those additional interfaces, and if
> the octet-counters for those additional (dummy) interfaces are always zero,
> the following might help:
>
> ---exceptions ---
> <OctetOut> : only : 0
>
> in which <OctetOut> is the name variable in the template containing the
> output octet counter. This variable should be used in the TABLE as well. If
> it works, it suppresses the lines in the table in which the output octet
> counter is zero. Thus it should suppress the second occurrence of
> interfaces. It is however not a nice solution.
>
> Regards,
>    Wim Nelis.
>
>
>
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Devmon-support mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devmon-support
>