February 2011 - Xymon - Xymon mailman web

VDEF in hobbitgraph.cfg
by roel.baardman＠dnw.aero 18 Feb '11

18 Feb '11

Hi All, Please excuse me if I'm asking questions previously answered, and point me towards the nearest place to RTFM. I'm using xymon 4.2.0.dfsg-14lenny3 on Debian 5.0.8. I'm attempting to integrate Smokeping graphs into the trends pages. I already played around in hobbitgraph.cfg and got the first graphs working. In an attempt to really create the 'smoke' graphs like smokeping creates, I started fiddling around with VDEF (STDEV in particular) on hobbitgraph.cfg (after changing the GRAPHS variable in hobbitserver.cfg). However, it appears any line with a VDEF statement in it results in no graph being created. I haven't found any logs on what happens during graph generation thus far. I've tried handing the relevant lines to rrdtool directly, including the VDEF line, and it was able to create a graph. I'm therefore wondering if VDEF is somehow unsupported or broken, or if I'm missing something obvious. Regards, Roel __________ Information from ESET NOD32 Antivirus, version of virus signature database 5886 (20110218) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

2 2

RE: Mailack delay problems
by henrik＠hswn.dk 18 Feb '11

18 Feb '11

Hi Johan In <B08F3F3D67451844A7A8A029FCC71E4C18DAA3E5FD at WIN01.ad.deltamanagement.se> =?iso-8859-1?Q?Johan_Sj=F6berg?= <johan.sjoberg at deltamanagement.se> writes: >I tested on another alert now, and it works if I remove the unnecessary par= >ts of the subject, for example if I change it to "Re: Hobbit [455503] delay= >=3D600". So maybe it's the subject that is too long or something when it is= > not working. It's possible, but your subject line would have to be very long for this to fail - longer than 1 KB. Sounds a bit odd if that is really the case. The attached diff removes this restriction, so if this solves the problem I would like to know. I'll probably do this change anyway, since it is a bit silly to have these random limits. Regards, Henrik Index: xymond/xymon-mailack.c =================================================================== --- xymond/xymon-mailack.c (revision 6631) +++ xymond/xymon-mailack.c (working copy) @@ -68,8 +68,8 @@ else if ((strncasecmp(STRBUF(inbuf), "ack=", 4) == 0) || (strncasecmp(STRBUF(inbuf), "ack ", 4) == 0)) { /* Some systems cannot generate a subject. Allow them to ack * via text in the message body. */ - subjectline = (char *)malloc(1024); - snprintf(subjectline, 1023, "Subject: Xymon [%s]", STRBUF(inbuf)+4); + subjectline = (char *)malloc(STRBUFLEN(inbuf) + 1024); + sprintf(subjectline, "Subject: Xymon [%s]", STRBUF(inbuf)+4); } else if (*STRBUF(inbuf) && !firsttxtline) { /* Save the first line of the message body, but ignore blank lines */

2 1

error on display
by David.Raymond＠ca.ebarrette.com 17 Feb '11

17 Feb '11

Hi, When I click on column to see what append, I get this Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, webmaster at localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. ________________________________ Apache/2.2.16 (Ubuntu) Server at xymon-mon01 Port 80 But, the xymon server is ok. What I need to check ? David Raymond

2 1

PID changes / Xymon restart
by tseglard＠wat.tv 17 Feb '11

17 Feb '11

Hello, I got a very strange behaviour on my platform with the Xymon client. The cient process don't stop to change PID (and sometimes the process stops running without any reasons), I could see this behaviour thanks to Monit and here is an extract from the log : CET Feb 14 14:28:29] info : 'xymon-client' PID has not changed [CET Feb 14 14:46:29] error : 'xymon-client' process PID changed to 2687 [CET Feb 14 14:48:29] info : 'xymon-client' PID has not changed [CET Feb 14 15:08:29] error : 'xymon-client' process PID changed to 21173 [CET Feb 14 15:10:30] info : 'xymon-client' PID has not changed [CET Feb 14 15:28:31] error : 'xymon-client' process is not running [CET Feb 14 15:28:31] info : 'xymon-client' trying to restart [CET Feb 14 15:28:31] info : 'xymon-client' start: /etc/init.d/xymon-client [CET Feb 14 15:30:31] info : 'xymon-client' process is running with pid 7355 [CET Feb 14 15:50:32] error : 'xymon-client' process PID changed to 24896 [CET Feb 14 15:52:32] info : 'xymon-client' PID has not changed [CET Feb 14 16:10:32] error : 'xymon-client' process PID changed to 10575 [CET Feb 14 16:12:32] info : 'xymon-client' PID has not changed [CET Feb 14 16:30:33] error : 'xymon-client' process PID changed to 28689 As a consequence each time PID changes, Puppet restarts Xymon client and after few hours I see a lot of hobbitlaunch process confusing some of my tests and filling up $XYMONHOME/tmp directory. I'm using Xymon for 4 years and never saw this before. My platform runs with Centos5.5 x86_64 and Xymon 4.2.3. Why does Xymon change its PID like that ? Why does it suddenly stops running (no trace of segfault in logs) ? This problem is now very annoying thus any ideas or advices will be appreciated J Sincerly, Thomas S

2 2

ifstat trends and FreeBSD8
by alevin＠gmail.com 16 Feb '11

16 Feb '11

Hi, I've found an issue with ifstat trends when the client is on FreeBSD8 Current version of netstat on BSD introduced field Idrop , so result of netstat command looks like: # netstat -i -b -n | egrep -v "^lo|<Link" Name Mtu Network Address Ipkts Ierrs Idrop Ibytes Opkts Oerrs Obytes Coll bge0 1500 192.168.X.X 192.168.X.X 29292829 - - 1130285651 26543376 - 2832025203 - bge0 1500 192.168.X.X 192.168.X.X 9 - - 756 0 - 0 - and as result rrd/do_ifstat.c can't pares it properly as a temporary workaround I've compiled previous version of netstat ( without Idrop filed ) on FreeBSD boxes and using it in the xymon client. Hope it can be handled by do_ifstat Thanks --- Alex

1 0

Wrong status text in mail alerts, from monitoring windows services with bbwin clients
by martin.blomdahl＠jonkopingenergi.se 16 Feb '11

16 Feb '11

Hi Running xymon 4.3.0.RC1 The text in alerts mail for windows servers running bbwin shows wrong status. The alert is correct, but the text is wrong. Here is the mail text. red Wed Feb 16 14:13:54 2011 - Services NOT ok &green LanmanServer is started/automatic - want started/automatic ....removed lines .......... &red VMTools is started/automatic - want started/automatic <<<<<--- Wrong Text, should be "is stopped/automatic " Here is the client data. Name StartupType Status DisplayName AeLookupSvc automatic started Application Experience .....removed lines .... VMTools automatic stopped VMware Tools Service VMUpgradeHelper automatic stopped VMware Upgrade Helper The SMS text using BBALPHAMSG variable, shows the same text as the mail. Minor problem, but a fix before 4.3.0 final would be nice. Regards Martin

1 0

Fwd: [xymon] msgs : always green instead of configuring for errors
by akshar.bhosale＠gmail.com 16 Feb '11

16 Feb '11

Hi, Thank you for pointing the mistake; but even after changing the setting, it is not working. Here are my changed settings in hobbit-clients.cfg Hosts are host1.abc.pqr.xyz----host50.abc.pqr.xyz HOST=%.*.abc.pqr.xyz LOG /var/log/messages lockup COLOR=red DEFAULT # These are the built-in defaults. UP 1h LOAD 18.0 20.0 DISK * 90 95 MEMPHYS 100 101 MEMSWAP 50 80 MEMACT 90 97 Even after restarting server and client, it is showing the same behaviour. Kindly let me know i -akshar ---------- Forwarded message ---------- From: pankaj dorlikar <pankaj.dorlikar at gmail.com> Date: Mon, Feb 14, 2011 at 6:05 PM Subject: Re: [xymon] msgs : always green instead of configuring for errors To: akshar.bhosale at gmail.com On Mon, Feb 14, 2011 at 12:00 PM, Henrik Størner <henrik at hswn.dk> wrote: > In <AANLkTikfYsvxA4dTTgTVrhQCFGG-vMQOAZ8XbvJHc_57 at mail.gmail.com> akshar > bhosale <akshar.bhosale at gmail.com> writes: > > >i am using xymon 4.2.2. I want that each client should show msgs red if > >lockup word comes in /var/log/messages. > > >~xymon/server/etc/hobbit-clients.cfg > >DEFAULT > > # These are the built-in defaults. > > UP 1h > > LOAD 18.0 20.0 > > DISK * 90 95 > > MEMPHYS 100 101 > > MEMSWAP 50 80 > > MEMACT 90 97 > > PROC cron > > PROC /opt/PBS/bin/myscript.sh > > LOG /var/log/messages lockup COLOR=red > > You should Never, Ever, put PROC and LOG settings in the > DEFAULT section. > > Move them into a "HOST=*" section, before the DEFAULT one. > > > Regards, > Henrik > > > To unsubscribe from the xymon list, send an e-mail to > xymon-unsubscribe at xymon.com >

3 3

weird thing in trending
by olivier＠audry.fr 15 Feb '11

15 Feb '11

hello xymon 4.3.0-RC1. I'm doing : xymon 127.0.0.1 "data xxxxxxxxxxx.trends `cat test`" with test : [testqos.rrd] DS:in:GAUGE:600:0:U 21 DS:out:GAUGE:600:0:U 8 On the xymon server I get on the rrd_channel : @@data#11/xxxxxxxxxxx|1297775436.696520|127.0.0.1||xxxxxxxxxxxxxxxxxxxxx|trends||pn data xxxxxxxxxxxxx.trends [testqos.rrd] DS:in:GAUGE:600:0:U 21 DS:out:GAUGE:600:0:U 8 @@ should be ok. But the strange thing is in the rrd_data debug log : 20303 2011-02-15 14:10:36 xymond_rrd: Got message 11 @@data#11/xxxxxxxxxxxxxxx|1297775436.696520|127.0.0.1||xxxxxxxxxxxxxxxxxxx|trends||pn 20303 2011-02-15 14:10:36 startpos 10451, fillpos 10451, endpos -1 20303 2011-02-15 14:10:36 Creating rrd /opt/xymon//data/rrd/xxxxxxxxxxxxxx/vmstat.rrd 20303 2011-02-15 14:10:36 RRD create param 00: 'rrdcreate' 20303 2011-02-15 14:10:36 RRD create param 01: '/opt/xymon//data/rrd/xxxxxxxxxxxxxxxx/vmstat.rrd' 20303 2011-02-15 14:10:36 RRD create param 02: '-s' 20303 2011-02-15 14:10:36 RRD create param 03: '300' 20303 2011-02-15 14:10:36 RRD create param 04: 'DS:in:GAUGE:600:0:U' 20303 2011-02-15 14:10:36 RRD create param 05: 'DS:out:GAUGE:600:0:U' 20303 2011-02-15 14:10:36 RRD create param 06: 'RRA:AVERAGE:0.5:1:576' 20303 2011-02-15 14:10:36 RRD create param 07: 'RRA:AVERAGE:0.5:6:576' 20303 2011-02-15 14:10:36 RRD create param 08: 'RRA:AVERAGE:0.5:24:576' 20303 2011-02-15 14:10:36 RRD create param 09: 'RRA:AVERAGE:0.5:288:576' the data are going into vmstat.rrd. WTF ? :) I test the same thing on another xymon rc1 set up and I don't have this kind of issue. But Henrik, do you have an idee ? many thx oau

1 1

Hostbased override values hobbit-clients.cfg
by s.seitz＠netz-haut.de 14 Feb '11

14 Feb '11

Henrik, thank you! Sometimes it's worth reading the man pages... shame on me ... Also to Ralph Mitchell, who offered the very same answer. Cheers, Stephan > >At the top of this file, defaults are defined: > > >DEFAULT > > LOAD 3.0 7.0 > > DISK * 86 92 > > [... and others ...] > > >Below there are single hosts defined (mostly PROC checking) > > > That's wrong. DEFAULT settings MUST go last, anything else should > be placed above it. > > It even says so in the file: > > # The special DEFAULT section can modify the built-in defaults - this > must > # be placed at the end of the file.

1 0

xymon_4.3.0-RC1: possible lost alerts
by dominique.frise＠unil.ch 14 Feb '11

14 Feb '11

Hi, I think I found a bug in xymond_alert.c. Lets say there is a page msg for hostA.serviceA and this alert will not be processed immediately because of this part of code: 816 /* 817 * When a burst of alerts happen, we get lots of alert messages 818 * coming in quickly. So lets handle them in bunches and only 819 * do the full alert handling once every 10 secs - that lets us 820 * combine a bunch of alerts into one transmission process. 821 */ 822 if (nowtimer < (lastxmit+10)) continue; 823 lastxmit = nowtimer; The main loop will then wait for a new msg from xymond (Want msg <num>, startpos... etc). Now if the next msg is a page recovery from the same hostA.serviceA, the next processing of the active alerts (for loop) will then cleanup the alert for hostA.serviceA without sending any alert. Dominique

2 7