August 2011 - Xymon - Xymon mailman web

xymon 4.3.4 trends column location
by icepickjazz＠gmail.com 03 Aug '11

03 Aug '11

I been testing xymond 4.3.4. The location of the trends column move from far left (first column) to the far right last column on the display pages. Is there a way to move it back to the old location? thanks

2 2

timediff
by malcolm.hunter＠gmx.com 03 Aug '11

03 Aug '11

> ----- Original Message ----- > From: Cami > Sent: 08/02/11 02:57 PM > To: xymon at xymon.com > Subject: Re: [Xymon] timediff > > BBWin builds the data file as it performs the tests, so it will always depend on how long it takes to do all of the tests. I'll raise a bug report to put the [clock] section at the end of the file. > > Much appreciated, this would save me (and i'm sure a lot others) a world > of headaches. Fixed for the next release. Malcolm

1 0

two tests showing purple and clear
by MMulligan＠llbean.com 02 Aug '11

02 Aug '11

It could be a space issue on the server with the purples. There may not be enough space to write out the entire *.msg file. You can compare the file sizes of the ones that work and the one that dosen't in $xymonhome/tmp. If it is trunacated some alerts will still work and the ines that do not will be purple or white. There may also be indicators in the log files on the client for hobbitclient.log /home/xymon/client/bin/hobbitclient-aix.sh: No space left on device ps: No space left on device /home/xymon/client/bin/hobbitclient-aix.sh: No space left on device cat: output error No space left on device /home/xymon/client/bin/hobbitclient.sh: No space left on device /home/xymon/client/bin/hobbitclient.sh: No space left on device Mark Mulligan ________________________________ From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Paul.A.Gallegos at wellsfargo.com Sent: Tuesday, July 26, 2011 1:05 PM To: xymon at xymon.com Subject: [Xymon] two tests showing purple and clear Ok, I'm stumped. I'm running Xymon 4.3.2 on a group of 10 RedHat 5.4 x64 servers, 4 of which are DB servers. 3 out of the four DB servers are showing green, the fourth shows clear for msgs (it says "no data reported") and purple for processes (over 20 days since something was reported). However, a ps command shows that the processes it should be checking for exist, and I can tail the log to see things scrolling through. I reinstalled the client on that server and it still won't go green. The configuration for all four DB servers is the same, outside of one script in ext/ directory. What could possibly be the problem?

1 0

AIX memory checks
by mailinglist0＠skurfer.com 02 Aug '11

02 Aug '11

On Aug 1, 2011, at 4:38 PM, Henrik Størner wrote: > What does the "[realmem]" section look like ? This is what it currently looks like (still red and reporting invalid numbers). The client is version 4.3.3, by the way. Server is 4.2.2-RC1 if it matters. [realmem] realmem 16777216 Amount of usable physical memory in Kbytes False [freemem] 0 0 1051672 5471551 0 0 0 0 0 0 10 577 525 1 3 96 0 0.03 6.7 [swap] Total Paging Space Percent Used 4096MB 1% > All of this is in the "client data" linked to from the detailed status page. It would be nice to have an example both when it is green and when it is red. It’s generally red, but here’s the same data from a nearly identical system that’s green. This one has more memory, but the configuration should be the same. [realmem] realmem 33554432 Amount of usable physical memory in Kbytes False [freemem] 9 3 9838132 4694881 0 0 0 909 947 0 2836 50135 29272 50 11 38 1 2.90 96.7 [swap] Total Paging Space Percent Used 4096MB 3% Thanks. -- Rob McBroom <http://www.skurfer.com/>

2 1

timediff
by malcolm.hunter＠gmx.com 02 Aug '11

02 Aug '11

> ----- Original Message ----- > From: Henrik Størner > Sent: 08/02/11 09:22 AM > To: xymon at xymon.com > Subject: Re: [Xymon] timediff > > Both the Xymon server and client machine (Windows) are syncing off the > > same router/source. The times look identical so where does the 138 > > seconds skew come from? > > First, see the explanation of the CLOCK setting in the analysis.cfg > man-page. > > The client inserts a timestamp in the client message, usually just > before it transmits the message to the Xymon server (not sure if that is > the case with BBWin, though - it might add the timestamp when it begins > collecting data, which could explain it if the eventlog scanning takes a > long time). This timestamp is then compared with the time that Xymon > receives the message. In your case, they are 138 seconds different. BBWin builds the data file as it performs the tests, so it will always depend on how long it takes to do all of the tests. I'll raise a bug report to put the [clock] section at the end of the file. Regards, Malcolm

2 1

Xymon PROC check fails on un-aligned ps(1) output
by cs＠schug.net 02 Aug '11

02 Aug '11

If have got a question regarding Xymon 4.3.3 (running on CentOS 5.6/x86_64). In order to monitor the existence of certain processes like rsyslogd(8) I have following process rule defined in analysis.cfg: CLASS=linux PROC "%^/sbin/rsyslogd -m 0$" This works fine as long as the columns in the output of ps(1) (more specific “ps -Aww -o pid,ppid,user,start,state,pri,pcpu,time,pmem,rsz,vsz,cmd” as defined in xymonclient-linux.sh) are all nicely aligned. PID PPID USER STARTED S PRI %CPU TIME %MEM RSZ VSZ CMD [...] 4620 4607 68 Jun 17 S 22 0.0 00:00:00 0.0 860 12348 hald-addon-keyboard: listening on /dev/input/event0 4709 1 root Jun 17 S 17 0.0 00:00:00 0.0 496 8540 /usr/bin/hidd --server 4739 1 root Jun 17 S 21 0.0 00:11:14 0.0 3576 300132 /sbin/rsyslogd -m 0 6894 1 root Jun 17 S 18 0.0 00:00:00 0.0 1540 122008 automount 6918 1 root Jun 17 S 24 0.0 00:00:08 0.0 1224 63544 /usr/sbin/sshd The trouble starts when the process in question runs long enough (as seen on a different machine) so it does fit the reserved columns for that specific field, disturbing to whole output (process runtime is just one example, I suppose any value growing big enough to not fit anymore the reserved space would do to exploit this behavior): PID PPID USER STARTED S PRI %CPU TIME %MEM RSZ VSZ CMD [...] 5377 1 root May 24 S 21 0.0 00:00:00 0.0 444 3816 /sbin/mingetty tty4 5378 1 root May 24 S 20 0.0 00:00:00 0.0 444 3816 /sbin/mingetty tty5 5380 1 root May 24 S 19 0.0 00:00:00 0.0 444 3816 /sbin/mingetty tty6 5382 1 root May 24 S 22 0.0 00:00:00 0.0 496 3824 /sbin/agetty 9600 ttyS1 vt100 8734 1 root Jun 20 S 21 7.7 3-06:51:29 0.1 48640 292664 /sbin/rsyslogd -m 0 20468 262 root Jul 19 S 24 0.0 00:04:01 0.0 0 0 [pdflush] In this case the above regex does not seem to match anymore, because (apparently) the matching starts at some fixed column value. Just for fun and to double check I enhanced the process rule set by another rule: CLASS=linux PROC "%^/sbin/rsyslogd -m 0$" PROC "%^[0-9]+ /sbin/rsyslogd -m 0$" After doing so, indeed the first rule still fails while the second rule matches. So apparently the last digit of the VSZ field of rsyslogd(8) sneaked into the CMD field and gets matched by the PROC check. Is this a known bug, and if yes is there a good workaround for that apart from invoking a wrapper script in xymonclient-linux.sh which mangels the output of ps(1) accordingly? Thanks in advance! -cs

1 2

&JSHOSTLIST in maint_header
by Carl.Melgaard＠STAB.RM.DK 02 Aug '11

02 Aug '11

Hi, I noticed this line in the 4.3.4 maint_header file, which gives a javascript error when I use the "bb-hosts-1.3cgi"-script from cnaude.mdns.org. Is it used for anything? /melgaard

2 3

timediff
by camis＠mweb.co.za 02 Aug '11

02 Aug '11

Hi all, Could someone explain why the following would be occuring ----- Tue Aug 02 08:30:43 2011 NOT ok yellow System clock is 138 seconds off (max 60) local: Tue Aug 02 08:30:43 2011 UTC: Tue Aug 02 06:30:43 2011 ----- Both the Xymon server and client machine (Windows) are syncing off the same router/source. The times look identical so where does the 138 seconds skew come from? Regards, Cami

2 1

FW: timediff
by redrocketed＠gmail.com 02 Aug '11

02 Aug '11

We had this problem on windows machines, bbwin was analyzing the windows event logs which took the length of time of the reported timediff. We had 100,000 log lines in the application log alone, these over-wrote themselves every 20-30 minutes, even when you set a rule for bbwin to ignore these logs it still must process the 100,000 lines in order to realize it can ignore them. Our solution was to stop the application (mssql) logging these useless "login succeeded" events to the application log. For a short term test you could unload msgs.dll on the client side (if possible) which I believe processes event logs, or you could clear or limit the event log. Steve -----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Cami Sent: Tuesday, August 02, 2011 8:53 AM To: xymon at xymon.com Subject: [Xymon] timediff Hi all, Could someone explain why the following would be occuring ----- Tue Aug 02 08:30:43 2011 NOT ok yellow System clock is 138 seconds off (max 60) local: Tue Aug 02 08:30:43 2011 UTC: Tue Aug 02 06:30:43 2011 ----- Both the Xymon server and client machine (Windows) are syncing off the same router/source. The times look identical so where does the 138 seconds skew come from? Regards, Cami ______________________________ > > _________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon >

1 0

Upgrading server to 4.3.4 - ok with clients still 4.2.3?
by Carl.Melgaard＠STAB.RM.DK 02 Aug '11

02 Aug '11

Hi, Can I still roll with the old clients from 4.2-branch even tho Im upgrading my server to 4.3.4? /melgaard

2 1