[Xymon] Memory data handling from Windows clients

zak.beck at accenture.com zak.beck at accenture.com
Fri Jan 29 17:59:48 CET 2016


Hi

 

Yeah, 2.05 is internal only and 2.1 is not released yet - waiting to see how
you get on with it, John!

 

The memory code in XymonPS has not been changed since 2010 (before I started
maintaining it) so any version of XymonPS should be fine with this server
side change.

 

2.1 contains some big news for anyone wanting to run external scripts on
Windows, hopefully coming soon.

 

Zak Beck



From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Rothlisberger,
John R.
Sent: 29 January 2016 15:31
To: xymon at xymon.com
Subject: Re: [Xymon] Memory data handling from Windows clients

 

I should note that this was done with the following version: 4.3.21 and
XymonPS 2.05 & 2.1 (may not yet be released).

 

Thanks, 

John 

Upcoming PTO: 

_____________________________________________________________________ 

John Rothlisberger

IT Strategy, Infrastructure & Security - Technology Growth Platform

TGP for Business Process Outsourcing

Accenture

312.693.3136 office

_____________________________________________________________________ 

 

From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Rothlisberger,
John R.
Sent: Thursday, January 28, 2016 2:04 PM
To: xymon at xymon.com <mailto:xymon at xymon.com> 
Subject: [Xymon] Memory data handling from Windows clients

 

We recently experienced a series of memory alerts on our windows servers
that didn't make sense.  Although Xymon was indicating that virtual memory
was completely used, logging into the server itself showed there were no
issues.

 

At first, I had thought there was something wrong with the data that the
XymonPS client was sending and working with Zak Beck we found a small tidbit
of code to resolve a "bbwin bug".

By flopping a 0 to a 1 we could reverse the way the numbers were reported
and yet this didn't resolve the problem.

 

It became obvious that the data being sent from the XymonPS client was
correct but once on the server something was getting handled differently.

 

Below is a detailed look at what we were seeing and then how I corrected it.
The corrections may or may not want to be included in future code releases.

 

 

Here is what the XymonPS data looked like when we were getting alerts.  

As you can see there is nothing that would indicate a problem:

[memory]

memory    Total    Used

physical: 4095 1266

virtual: 4506 4111  <--- These are the numbers we are interested in.

page: 8600 5297

 

 

This is what was the Xymon server used to create our alert:

Memory              Used      Total  Percentage

Physical           1266M      4095M         30%

Actual             4111M  >>> 4095M <<<    100% <--- Here is the alert

Swap               5297M      8600M         61%

 

As you can see - the "Total" available "Actual" memory is the same as the
Total available Physical memory.  But, this is not right, the total
available Actual memory should have been 4506M.

 

Just for the sake of having this information included, here is what the
memory data looks like from a linux client (there is no issue here):

Linux data:

[free]

             total       used       free     shared    buffers     cached

Mem:      16556808    4895408   11661400          0     259376    2508448

-/+ buffers/cache:    2127584   14429224

Swap:      1340412          0    1340412

 

Displayed:

Memory              Used       Total  Percentage

Physical           4780M      16168M         29%

Actual             2077M      16168M         12%

Swap                  0M       1308M          0%

 

 

So, I had to find out why the total physical memory was used to calculate
the percentage of used space for the "Actual" memory when the client is a
Windows server (XymonPS or BBWin).

What I found was that although there is a variable used for memactused there
was nothing for memacttotal.  So I added a new value for memacttotal which
then required me to add the same values to bbwin.c (see below).

This also required a modification to linux.c (see below) which instead of
using memacttotal, it simiply reususes the value for memphytotal which is
essencially the same thing that is currently being done now.

Although I have provided patch files for bbwin.c and linux.c ALL of the
xymond/client/*.c files need to be modified.

 

xymond_client.c patch:

--- xymond_client.c.ORIG        2016-01-27 09:53:58.321793949 -0600

+++ xymond_client.c     2016-01-28 12:57:51.676006980 -0600

@@ -909,7 +909,7 @@

 

void unix_memory_report(char *hostname, char *clientclass, enum ostype_t os,

                        void *hinfo, char *fromline, char *timestr,

-                       long memphystotal, long memphysused, long
memactused,

+                       long memphystotal, long memphysused, long
memacttotal, long memactused,

                        long memswaptotal, long memswapused)

{

        long memphyspct = 0, memswappct = 0, memactpct = 0;

@@ -938,7 +938,7 @@

                if (memswappct > swapred)    swapcolor = COL_RED;

        }

 

-       if (memactused != -1) memactpct = (memphystotal > 0) ? ((100 *
memactused) / memphystotal) : 0;

+       if (memactused != -1) memactpct = (memacttotal > 0) ? ((100 *
memactused) / memacttotal) : 0;

        if (memactpct <= 100) {

                if (memactpct  > actyellow)  actcolor  = COL_YELLOW;

                if (memactpct  > actred)     actcolor  = COL_RED;

@@ -965,30 +965,30 @@

                memorysummary);

        addtostatus(msgline);

 

-       sprintf(msgline, "   %-12s%12s%12s%12s\n", "Memory", "Used",
"Total", "Percentage");

+       sprintf(msgline, "   %-16s%12s%12s%12s\n", "Memory", "Used",
"Total", "Percentage");

        addtostatus(msgline);

 

-       sprintf(msgline, "&%s %-12s%11ldM%11ldM%11ld%%\n",

-               colorname(physcolor), "Physical", memphysused, memphystotal,
memphyspct);

+       sprintf(msgline, "&%s %-16s%11ldM%11ldM%11ld%%\n",

+               colorname(physcolor), "Real/Physical", memphysused,
memphystotal, memphyspct);

        addtostatus(msgline);

 

        if (memactused != -1) {

                if (memactpct <= 100)

-                       sprintf(msgline, "&%s %-12s%11ldM%11ldM%11ld%%\n",

-                               colorname(actcolor), "Actual", memactused,
memphystotal, memactpct);

+                       sprintf(msgline, "&%s %-16s%11ldM%11ldM%11ld%%\n",

+                               colorname(actcolor), "Actual/Virtual",
memactused, memacttotal, memactpct);

                else

-                       sprintf(msgline, "&%s %-12s%11ldM%11ldM%11ld%% -
invalid data\n",

-                               colorname(COL_CLEAR), "Actual", memactused,
memphystotal, 0L);

+                       sprintf(msgline, "&%s %-16s%11ldM%11ldM%11ld%% -
invalid data\n",

+                               colorname(COL_CLEAR), "Actual/Virtual",
memactused, memacttotal, 0L);

 

                addtostatus(msgline);

        }

 

        if (memswapused != -1) {

                if (memswappct <= 100)

-                       sprintf(msgline, "&%s %-12s%11ldM%11ldM%11ld%%\n",

-                               colorname(swapcolor), "Swap", memswapused,
memswaptotal, memswappct);

+                       sprintf(msgline, "&%s %-16s%11ldM%11ldM%11ld%%\n",

+                               colorname(swapcolor), "Swap/Page",
memswapused, memswaptotal, memswappct);

                else

-                       sprintf(msgline, "&%s %-12s%11ldM%11ldM%11ld%% -
invalid data\n",

+                       sprintf(msgline, "&%s %-16s%11ldM%11ldM%11ld%% -
invalid data\n",

                                colorname(COL_CLEAR), "Swap", memswapused,
memswaptotal, 0L);

 

                addtostatus(msgline);

 

 

 

 

 

bbwin.c patch:

--- bbwin.c.ORIG        2016-01-27 09:54:13.989793661 -0600

+++ bbwin.c     2016-01-27 09:54:17.709793593 -0600

@@ -487,7 +487,7 @@

                if (p) sscanf(p, "\nvirtual: %ld %ld", &memacttotal,
&memactused);

                dbgprintf("DEBUG Memory %ld %ld %ld %ld %ld\n",
memphystotal, memphysused, memactused, memswaptotal, memswapused); /* DEBUG
TODO Remove*/

                 unix_memory_report(hostname, clienttype, os, hinfo,
fromline, timestr,

-                                   memphystotal, memphysused, memactused,
memswaptotal, memswapused);

+                                   memphystotal, memphysused, memacttotal,
memactused, memswaptotal, memswapused);

         }

 

        splitmsg_done();

 

linux.c patch:

--- linux.c.ORIG        2016-01-27 09:54:23.861793480 -0600

+++ linux.c     2016-01-27 09:54:27.545793413 -0600

@@ -135,7 +135,7 @@

                }

 

                unix_memory_report(hostname, clienttype, os, hinfo,
fromline, timestr,

-                                  memphystotal, memphysused, memactused,
memswaptotal, memswapused);

+                                  memphystotal, memphysused, memphystotal,
memactused, memswaptotal, memswapused);

        }

 

        if (mdstatstr) {

 

 

 

After modifications the data from the client remains the same but what the
server acts upon and displays now looks like:

 

Windows/XymonPS:

Memory                  Used       Total  Percentage

Real/Physical          1444M       5119M         28%

Actual/Virtual           57M       2047M          2%

Swap/Page              1742M      10237M         17%

 

 

Linux:

Memory                  Used       Total  Percentage

Real/Physical          3625M       3949M         91%

Actual/Virtual          889M       3949M         22%

Swap/Page                 6M       4092M          0%

 

 

 

You will notice that I changed the labels of each line to include what the
names are in the graphs.  I figured if I was modifyng these scripts I might
as well fix what has been annoying me for a long long time.  :)

 

I hope this all makes sense.

 

 

 

 

 

 

 

Thanks, 

John 

Upcoming PTO: 

_____________________________________________________________________ 

John Rothlisberger

IT Strategy, Infrastructure & Security - Technology Growth Platform

TGP for Business Process Outsourcing

Accenture

312.693.3136 office

_____________________________________________________________________ 

 

 

  _____  


This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise confidential information. If you have
received it in error, please notify the sender immediately and delete the
original. Any other use of the e-mail by you is prohibited. Where allowed by
local law, electronic communications with Accenture and its affiliates,
including e-mail and instant messaging (including content), may be scanned
by our systems for the purposes of information security and assessment of
internal compliance with Accenture policy. 
____________________________________________________________________________
__________

www.accenture.com <http://www.accenture.com> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20160129/a0067a99/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6831 bytes
Desc: not available
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20160129/a0067a99/attachment.bin>


More information about the Xymon mailing list