TS - Problem ignoring 'mem' from Quest Windows Client 4.00 🔗 link

Team,

                I am at a loss.

                I am running Xymon 4.3.0-0.beta2 on a Dell R-610 running
CentOS 5.x.  I have a pair of them.

 
                We have multiple virtual Exchange servers on Win2003
server.

                All are reporting 'mem' problems up to 104%.

 
                We currently use the Quest BB 4.00 Windows client as I
converted the main server from BB to Xymon over 2 years ago.

                This was the best plan for the conversion as our Windows
admins already were acquainted with the GUI setup.

                Since we pay for maintenance from Quest on the client, I
opened a case with them but cannot tell them that the server is Xymon.

                Currently we want to stop the client from monitoring the
'mem'.  The GUI says to set the value above 100% for the alerts.

                The GUI will not let you set the values above 100 and
100 for yellow and red respectively.  

                P.S.  This does work for disk drives though.

 
                Quest says to add this parameter to the bb-host file of
'nomem' - this does not seem to do anything.

 
The also want to change the bbwarnrules to:  *;;*;*;user-f6feced0718a@xymon.invalid

                Not sure what this is accomplishing?

I still need alerting for all the other items from the current client.

 
Disabling the test, is not the answer as it bounces up and down all day
long.

 
I also tried to add an entry for each host in the
/home/xymon/client/etc/localclient.cfg 

and to hobbitclient.cfg at the bottom of the file:

                
HOST=slxcg01.csw.l-3com.com

        MEMPHYS 110 120

        MEMSWAP 50 80

        MEMACT  90 97

 
HOST=slxcg02.csw.l-3com.com

        MEMPHYS 110 120

        MEMSWAP 50 80

        MEMACT  90 97

 
HOST=slxcg03.csw.l-3com.com

        MEMPHYS 110 120

        MEMSWAP 50 80

        MEMACT  90 97

 
Still seeing RED  for 'mem' Icon    J

 
Thanks,

 
Tom Schmitt

Senior IT Staff - R&D

L-3 Communication Systems West

640 North 2200 West    P.O. Box 16850

Salt Lake City, UT  XXXXX

Phone (XXX) XXX-XXXX

Cell      (XXX) XXX-XXXX

eFax    (XXX) XXX-XXXX

            \\\\||////

               \ ~  ~ /  

               | @  @ |

--oOo---(_)---oOo--

Have A Nice Day !

Haven't used a Quest/BB client in years, and certainly not this one, so I am guessing - albeit a rather qualified guess.

My guess is that this - on a Big Brother server - would work somewhat like "noping" does, i.e. it causes the server to ignore a red status and instead it shows a "clear" status.

Xymon doesn't have an exact equivalent. There is a "NOCOLUMNS" setting, but it will currently not work for clients that generate the status message themselves, only for Xymon clients where data is analyzed on the Xymon server.

Why can't you just disable it for 5 years ? A time-based disable is not affected by the status bouncing red/green, it stays in effect until the time expires.

These files only have effect on systems running a Xymon client; it requires the client to send "raw" data into the Xymon server, which the xymond_client running on the Xymon server will then analyze and change into status messages.


It seems to me that you are not getting the support you pay for. A client reporting "104 % memory used" is obviously broken - a system cannot use more memory than it has. So trying to "fix" it by removing the memory-column from your display and/or disabling alerts is a non-solution; it hides the underlying problem instead of solving it. I mean - if they get the memory-utilisation wrong, how do you know the other data is correct ? Can you trust the other data it is reporting ? Can you trust the memory-numbers it reports from your other systems ?


I haven't written the code for it, but I guess it would be fairly easy to implement something similar to "nomem", if all this does is to ignore the memory status coming from a host. An extension of the current "NOCOLUMNS" setting, so it works on all statuses - whether generated by a Xymon client or sent directly to the Xymon server. But I honestly don't think that is the correct solution.

Any chance of putting a BBWin client on those systems ? You could set it up for "central" mode and manage the configuration on the Xymon server, as you do with the Xymon unix clients - so your Windows admins wouldn't have to learn how to edit the BBWin XML config file.


Regards,
Henrik

On 01-09-2011 22:02, Henrik Størner wrote:

Something like this would do it - it compiles OK, but I haven't tested 
it; I still think it is the wrong solution.

Note that applying this directly to 4.3.0-beta 2 won't work. You really 
should think about upgrading your Xymon server.


Regards,
Henrik