[Xymon] Installing Xymon from terabithia; two weird issues
Matt Vander Werf
matt1299 at gmail.com
Sun Mar 19 11:05:18 CET 2017
Hi Peter,
Regarding #2, it looks like a memory leak with netapp data RRD templates
was fixed as part of the 4.3.28 release [1], and it looks like it says it
was reported by you as well [2]. Given that you said you're still using the
4.3.27 RPM, you might want to try and update to 4.3.28 and see if that
fixes your memory leak issue.
Hope this helps!
[1] https://sourceforge.net/p/xymon/code/7969/
[2] https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.3.28/Changes
--
Matt Vander Werf
On Fri, Mar 17, 2017 at 8:56 AM, Peter Welter <peter.welter at gmail.com>
wrote:
> Hi JC,
>
> I'm still experiencing some difficulties with Xymon version
> (4.3.27-1.el6.terabithia) software, that is being deployed from
> http://terabithia.org/rpms/xymon/el6/i686/.
>
> There are two different types of problems:
>
> 1) Has to do with the integration of Xymon/Devmon.
>
> Although Devmon gets valid SNMP-data, for each poll, the values in the
> if_load.Ethernet3_1.rrd-file (for example) are showing gaps. The next value
> is so much larger than the rest, so the total graph is going beserk because
> of the spikes that are being shown.
>
> ...[snip]
> <!-- 2017-03-15 15:10:00 CET / 1489587000 -->
> <row><v>5.7197560484e+01</v><v>5.7540255376e+01</v></row>
> <!-- 2017-03-15 15:15:00 CET / 1489587300 -->
> <row><v>5.8052253788e+01</v><v>5.7062462121e+01</v></row>
> <!-- 2017-03-15 15:20:00 CET / 1489587600 -->
> <row><v>5.8039204545e+01</v><v>5.7738579545e+01</v></row>
> <!-- 2017-03-15 15:25:00 CET / 1489587900 -->
> <row><v>5.8352395833e+01</v><v>5.7912187500e+01</v></row>
> <!-- 2017-03-15 15:30:00 CET / 1489588200 -->
> <row><v>5.7961458333e+01</v><v>5.8807500000e+01</v></row>
> <!-- 2017-03-15 15:35:00 CET / 1489588500 -->
> <row><v>5.7040675403e+01</v><v>5.7108262769e+01</v></row>
> <!-- 2017-03-15 15:40:00 CET / 1489588800 -->
> <row><v>5.7984999119e+01</v><v>5.8214662436e+01</v></row>
> <!-- 2017-03-15 15:45:00 CET / 1489589100 -->
> <row><v>1.6832224569e+16</v><v>1.6832224569e+16</v></row>
> <!-- 2017-03-15 15:50:00 CET / 1489589400 -->
> <row><v>4.4656922344e+16</v><v>4.4656922343e+16</v></row>
> <!-- 2017-03-15 15:55:00 CET / 1489589700 -->
> <row><v>5.7648150173e+01</v><v>5.7687031165e+01</v></row>
> <!-- 2017-03-15 16:00:00 CET / 1489590000 -->
> <row><v>5.9068884188e+01</v><v>5.9453689406e+01</v></row>
> <!-- 2017-03-15 16:05:00 CET / 1489590300 -->
> <row><v>NaN</v><v>NaN</v></row>
> <!-- 2017-03-15 16:10:00 CET / 1489590600 -->
> <row><v>NaN</v><v>NaN</v></row>
> <!-- 2017-03-15 16:15:00 CET / 1489590900 -->
> <row><v>NaN</v><v>NaN</v></row>
> <!-- 2017-03-15 16:20:00 CET / 1489591200 -->
> <row><v>NaN</v><v>NaN</v></row>
> <!-- 2017-03-15 16:25:00 CET / 1489591500 -->
> <row><v>NaN</v><v>NaN</v></row>
> <!-- 2017-03-15 16:30:00 CET / 1489591800 -->
> <row><v>1.9398478192e+07</v><v>1.8707899982e+07</v></row>
> <!-- 2017-03-15 16:35:00 CET / 1489592100 -->
> <row><v>5.6938284153e+01</v><v>5.6770437158e+01</v></row>
> <!-- 2017-03-15 16:40:00 CET / 1489592400 -->
> <row><v>NaN</v><v>NaN</v></row>
> <!-- 2017-03-15 16:45:00 CET / 1489592700 -->
> <row><v>NaN</v><v>NaN</v></row>
> <!-- 2017-03-15 16:50:00 CET / 1489593000 -->
> <row><v>NaN</v><v>NaN</v></row>
> <!-- 2017-03-15 16:55:00 CET / 1489593300 -->
> <row><v>NaN</v><v>NaN</v></row>
> <!-- 2017-03-15 17:00:00 CET / 1489593600 -->
> <row><v>NaN</v><v>NaN</v></row>
> <!-- 2017-03-15 17:05:00 CET / 1489593900 -->
> <row><v>NaN</v><v>NaN</v></row>
> <!-- 2017-03-15 17:10:00 CET / 1489594200 -->
> <row><v>NaN</v><v>NaN</v></row>
> <!-- 2017-03-15 17:15:00 CET / 1489594500 -->
> <row><v>NaN</v><v>NaN</v></row>
> <!-- 2017-03-15 17:20:00 CET / 1489594800 -->
> <row><v>NaN</v><v>NaN</v></row>
> <!-- 2017-03-15 17:25:00 CET / 1489595100 -->
> <row><v>3.5775056887e+07</v><v>3.4501518955e+07</v></row>
> <!-- 2017-03-15 17:30:00 CET / 1489595400 -->
> <row><v>5.7219344262e+01</v><v>5.7417704918e+01</v></row>
> <!-- 2017-03-15 17:35:00 CET / 1489595700 -->
> <row><v>5.7166338798e+01</v><v>5.9383825137e+01</v></row>
> <!-- 2017-03-15 17:40:00 CET / 1489596000 -->
> <row><v>5.6769617486e+01</v><v>5.6981202186e+01</v></row>
> <!-- 2017-03-15 17:45:00 CET / 1489596300 -->
> <row><v>5.7549617486e+01</v><v>5.7382732240e+01</v></row>
> ...[snip]
> This behaviour does NOT occur on my current Xymon server (version
> 4.2.3) running on SLES11 SP4.
>
> First I thought that this has to do with vmware, but that is not the
> case. VM or bare metal; the behaviour is the same.
>
> I made sure to see that even the devmon module is not causing the
> problems. The same devmon software works fine on SLES and RHEL. The
> snmpwalk-command does get valid SNMP-data, when writing to a files. It just
> seems that Xymon does not update the rrd-file correctly!?!?
>
> Any suggestions how to proceed?
>
> 2) Is a memory leak that only occurs when the NetApp-plugin (
> https://sourceforge.net/projects/hobbit-perl-cl/) is being used for
> trending data. Unfortunately, this not maintained anymore.
>
> In the past I have been trying to troubleshoot this problem with you
> using valgrind etc.
>
> What do you suggest? Should I upgrade to the newest version first?
>
> Kind regards, Peter
>
>
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20170319/d47203ec/attachment.html>
More information about the Xymon
mailing list