- Xymon - Xymon mailman web

No graph for negative clock offset
by david＠stufflemail.com 28 Jul '08

28 Jul '08

Hi all, None of my clock offset graphs graph anything when the clock offset from a host is a negative number. Only positive number work. Anyone having the same thing happen or know how to fix? I'm running a snapshot 4.3.0-0.20080103 Thanks David

3 3

Graphs are missing data, but it's there!
by Martin.Ward＠colt.net 28 Jul '08

28 Jul '08

All, I have a problem with one machine where its data is not being shown in the graphs even though the data exists. The machine in question's Hobbit client sends five pieces of numeric data (email queues) and these are displayed on the web page for this service: ==== Thursday July 24 11:29:11 UTC 2008 ActiveStatus: green <http://hbt0.lon.oss.colt.net/hobbit/gifs/green.gif> ActiveQueue: 106 ActiveTrend: tendency rising with -60 mails. BounceStatus: green <http://hbt0.lon.oss.colt.net/hobbit/gifs/green.gif> BounceQueue: 58 BounceTrend: tendency falling with 3 mails. DeferStatus: red <http://hbt0.lon.oss.colt.net/hobbit/gifs/red.gif> DeferQueue: 150464 DeferTrend: tendency falling with 95 mails. CorruptStatus: green <http://hbt0.lon.oss.colt.net/hobbit/gifs/green.gif> CorruptQueue: 0 CorruptTrend: amount equal to last measure. IncomingStatus: red <http://hbt0.lon.oss.colt.net/hobbit/gifs/red.gif> IncomingQueue: 247049 IncomingTrend: amount equal to last measure. Deferred Queue is too high but is decreasing already. ==== These numbers change over time and the values are accurate. However, the graph that is displayed below this data is blank. I have historic data, the files exist, and what is more I have other machines that are configured identically to this one where the data IS graphed correctly. Hobbit graphs are a bit of a black hole to me, can anyone suggest where I might look? |\/|artin ************************************************************************************* The message is intended for the named addressee only and may not be disclosed to or used by anyone else, nor may it be copied in any way. The contents of this message and its attachments are confidential and may also be subject to legal privilege. If you are not the named addressee and/or have received this message in error, please advise us by e-mailing security at colt.net and delete the message and any attachments without retaining any copies. Internet communications are not secure and COLT does not accept responsibility for this message, its contents nor responsibility for any viruses. No contracts can be created or varied on behalf of COLT Telecommunications, its subsidiaries or affiliates ("COLT") and any other party by email Communications unless expressly agreed in writing with such other party. Please note that incoming emails will be automatically scanned to eliminate potential viruses and unsolicited promotional emails. For more information refer to www.colt.net or contact us on +44(0)20 7390 3900.

6 12

Bug Report: Critical error in log couldn't be sent to server every time
by Samuel.Cai＠ehealth-china.com 28 Jul '08

28 Jul '08

Hi, My company is using Hobbit (4.2) to monitor OutOfMemoryError and StackOverflowError in application log, but we found out sometimes Hobbit client did not send data which contains these error strings to server, that resulted in no error reported. Below is our configuration snippet in client-local.cfg, as you can see, although we set maximum amount of data to 10240 bytes, we also set trigger on key word of Error, so even if there is more data in the log than the maximum size set, those matched error string should be sent to server in any case: [our server] log:/home/mine/server.log:10240 trigger Error So I'm thinking two possible reasons: 1. The regular expression for trigger is wrong. 2. There's a bug/limitation in logfetch tool, it can only process a maximum data, for example, if application happened to write 100M data to log file in 5 mins, this tool will only process, say last 10M data. I made some tests to find out root reason, each test contains two steps: 1. Clean log, wait after client sends out data. 2. Fill in some data into log, the first line is "OutOfMemoryError StackOverflowError", others are just garbage data. Here is the result, I list the lines (L) and bytes (C) of log after filled in data: 1. 485L, 54545C, catch error 2. 1445L, 163025C, couldn't catch error 3. 707L, 53771C, couldn't catch error 4. 468L, 36451C, couldn't catch error 5. 226L, 18615C, catch error The test proves that the trigger pattern is correct, and logfetch tool has an issue to process all new data if it's large (in lines or in bytes, I don't know). We need to fix it or have a workaround, since these errors are so important, we shouldn't miss them. Thanks, Samuel Cai

3 7

SCRIPT alert problem with SERVICE=
by rrosenkoetter＠tradebotsystems.com 25 Jul '08

25 Jul '08

I'm having problems understanding how matching is done by hobbit for sending alerts via the SCRIPT command. I have separated out the services I want to monitor into two different SCRIPT events, because we want to monitor disk and connection alerts 24/7, but cpu, mem, tbntp, and procs only during the day. Here's the appropriate part of the hobbit-alerts.cfg file PAGE=KC/KC-Test SCRIPT /home/hobbit/server/ext/mail-format-alert.py SERVICE=disk,conn DURATION>1m REPEAT=20 COLOR=yellow,red RECOVERED TIME=W:0000:2359 SCRIPT /home/hobbit/server/ext/mail-format-alert.py SERVICE=cpu,mem,tbntp,procs DURATION>1m REPEAT=20 COLOR=yellow,red RECOVERED TIME=W:0700:1700 MAIL ron at whatever.com SERVICE=cpu,mem,tbntp,procs DURATION>1m REPEAT=20 COLOR=yellow,red RECOVERED TIME=W:0000:2359 MAIL ron at whatever.com SERVICE=conn,disk DURATION>1m REPEAT=20 COLOR=yellow,red RECOVERED TIME=W:0700:1700 However, whenever hobbit generates ANY alert it matches on both SCRIPT lines, and sends the alert twice. It doesn't appear to care about the SERVICE parameter. Here's the results I get when running a test alert ../bin/bbcmd hobbitd_alert --test test2003 cpu 500 00016539 2008-07-24 13:52:16 send_alert test2003:cpu state Paging 00016539 2008-07-24 13:52:16 Matching host:service:page 'test2003:cpu:KC/KC-Test' against rule line 124 00016539 2008-07-24 13:52:16 *** Match with 'PAGE=KC/KC-Test' *** 00016539 2008-07-24 13:52:16 Matching host:service:page 'test2003:cpu:KC/KC-Test' against rule line 125 00016539 2008-07-24 13:52:16 *** Match with 'SCRIPT /home/hobbit/server/ext/mail-format-alert.py SERVICE=conn,disk DURATION>1m REPEAT=20 COLOR=yellow,red RECOVERED TIME=W:0000:2359' *** 00016539 2008-07-24 13:52:16 Script alert with command '/home/hobbit/server/ext/mail-format-alert.py' and recipient SERVICE=conn,disk 00016539 2008-07-24 13:52:16 Matching host:service:page 'test2003:cpu:KC/KC-Test' against rule line 126 00016539 2008-07-24 13:52:16 *** Match with 'SCRIPT /home/hobbit/server/ext/mail-format-alert.py SERVICE=cpu,mem,tbntp,procs DURATION>1m REPEAT=20 COLOR=yellow,red RECOVERED TIME=W:0700:1700' *** 00016539 2008-07-24 13:52:16 Script alert with command '/home/hobbit/server/ext/mail-format-alert.py' and recipient SERVICE=cpu,mem,tbntp,procs Note that it works properly with MAIL; the service doesn't match in line 128 and hobbit doesn't generate a MAIL event. 00018965 2008-07-24 13:52:16 Matching host:service:page 'test2003:cpu:KC/KC-Test' against rule line 127 00018965 2008-07-24 13:52:16 *** Match with 'MAIL ron at tradebotsystems.com SERVICE=cpu,mem,tbntp,procs DURATION>1m REPEAT=20 COLOR=yellow,red RECOVERED TIME=W:0700:1700' *** 00018965 2008-07-24 13:52:16 Mail alert with command 'mail -s "Hobbit [12345] test2003:cpu CRITICAL (RED)" ron at tradebotsystems.com' 00018965 2008-07-24 13:52:16 Matching host:service:page 'test2003:cpu:KC/KC-Test' against rule line 128 00018965 2008-07-24 13:52:16 Failed 'MAIL ron at tradebotsystems.com SERVICE=conn,disk DURATION>1m REPEAT=20 COLOR=yellow,red RECOVERED TIME=W:0000:2359' (service not in include list) So what's going on with SERVICE and the SCRIPT event? Any help would be appreciated.

1 1

compile error
by pnkumaresh＠gmail.com 24 Jul '08

24 Jul '08

Hey, could you help me on this .. i am getting this error during compile .. /usr/include/sys/siginfo.h:428: error: parse error before '}' token /usr/include/sys/siginfo.h:432: error: parse error before "k_siginfo_t" /usr/include/sys/siginfo.h:437: error: parse error before '}' token In file included from /usr/include/signal.h:26, from bbgen.c:22: /usr/include/sys/signal.h:85: error: parse error before "siginfo_t" In file included from bbgen.c:22: /usr/include/signal.h:111: error: parse error before "siginfo_t" /usr/include/signal.h:113: error: parse error before "siginfo_t" gmake[1]: *** [bbgen.o] Error 1 gmake[1]: Leaving directory `/var/tmp/hobbit-4.2.0/bbdisplay' gmake: *** [bbdisplay-build] Error 2 -- Best Regards Kumaresh

2 1

maint.pl to hobbit-enadis.sh
by jm54601＠yahoo.com 24 Jul '08

24 Jul '08

Using maint.pl on Big Brother, I used to be able to call this URL from a script to disable a host: http://bigbrother/cgi-bin/maint.pl?host="hostname"&reason=bbdisablescript&user=bbdisablescript&duration=7&tests=ALL&mode=disable&units=1440 In Hobbit calling a similar url (with tokens adapted) doesn't work: http://hobbit/hobbit-cgi/hobbit-enadis.sh?hostname=hostname&disabletest=ALL… Any ideas?

1 0

Metric report question
by Gert.Maaskant＠Centric.nl 24 Jul '08

24 Jul '08

Hi, We running hobbit in Linux and using a handmade complied version of Hobbit ( 4.3.0.0) When I select one server into the Metric Report screen it works fine, bud when I select more ( off the same) servers , I got only the "X" picture. Could it mean the I have a protection problem somewhere ? The last thing I tried was to change the protection to 777 , bud does not help. Regards, Gert Maaskant ------------------------------------------------------------------------ ----------------------- Doesburgweg 7 2803 PL Gouda, The Netherlands Tel. +31 182 56 26 00 Tel. +31 6 20534580 Fax (0182) 56 26 12 ------------------------------------- The information included in this message is personal and/or confidential and intended exclusively for the addressees as stated. This message and/or the accompanying documents may contain confidential information and should be handled accordingly. If you are not the intended reader of this message, we urgently request that you notify Centric immediately and that you delete this e- mail and any copies of it from your system and destroy any printouts immediately. It is forbidden to distribute, reproduce, use or disclose the information in this e-mail to third parties without obtaining prior permission from Centric. We expressly point out that there are risks associated with the use of e-mail. Centric and the companies within the group shall not accept any liability whatsoever for damage resulting from the use of e-mail. Legally binding obligations can only arise for Centric by means of a written instrument, signed by an authorized representative of Centric. -------------------------------------

1 0

[hobbit] "Info" column slow on latest snapshot (20080422)
by cncook001＠yahoo.com 24 Jul '08

24 Jul '08

Doh. Should have waited. It seems to have something to do with hosts with a client that reports full details, ie, disk, cpu, memory etc. I have some hosts doing ping only tests, info column is fine. Info column on Windows and Solaris clients that report in fail with a similar apache error eg. [Wed Jul 23 08:34:18 2008] [error] [client 10.10.10.2] Premature end of script headers: bb-hostsvc.sh, referer: http://hobbitmon.example.com/hobbit/Solaris/Solaris.html Craig

2 1

[hobbit] RECOVERED alerts red->yellow
by Martin.Ward＠colt.net 23 Jul '08

23 Jul '08

Hi Alan, I think there is some confusion because in your first email you said: > I've read the sections on ALERTCOLORS and OKCOLORS. It does work better > when I remove yellow from the list. But I need to sometimes alert on > yellow status, so this is not really an option. But here you state: > red->yellow->green. If I use only the COLOR=red,yellow, I'm > goind to get alerted on a yellow > disk (undesired). So we need to understand more clearly when you want to be alerted on red and yellow and when you don't. |\/|artin -- > -----Original Message----- > From: Alan Sparks [mailto:asparks at doublesparks.net] > Sent: 09 July 2008 06:53 > To: hobbit at hswn.dk > Subject: Re: [hobbit] RECOVERED alerts red->yellow > > > OK, I've tried: > SERVICE=disk COLOR=red > MAIL asparks at gobucket.com COLOR=red,yellow RECOVERED > > And even: > SERVICE=disk COLOR=red,yellow > MAIL asparks at gobucket.com COLOR=red RECOVERED > > And neither sends a recovery page when disk goes > red->yellow->green. If I use only the COLOR=red,yellow, I'm > goind to get alerted on a yellow > disk (undesired). > Did I misunderstand your suggestion? Thanks. > -Alan > > > Tim McCloskey wrote: > > Try the following in the specific line in hobbitalerts.cfg: > > COLOR=red,yellow > > > > > > Alan Sparks wrote: > >> I have the following rule in my hobbit-alerts.cfg: SERVICE=disk > >> COLOR=red > >> MAIL asparks at photobucket.com RECOVERED > >> > > > > > > To unsubscribe from the hobbit list, send an e-mail to > > hobbit-unsubscribe at hswn.dk > > > > > > > > > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > > ************************************************************************************* The message is intended for the named addressee only and may not be disclosed to or used by anyone else, nor may it be copied in any way. The contents of this message and its attachments are confidential and may also be subject to legal privilege. If you are not the named addressee and/or have received this message in error, please advise us by e-mailing security at colt.net and delete the message and any attachments without retaining any copies. Internet communications are not secure and COLT does not accept responsibility for this message, its contents nor responsibility for any viruses. No contracts can be created or varied on behalf of COLT Telecommunications, its subsidiaries or affiliates ("COLT") and any other party by email Communications unless expressly agreed in writing with such other party. Please note that incoming emails will be automatically scanned to eliminate potential viruses and unsolicited promotional emails. For more information refer to www.colt.net or contact us on +44(0)20 7390 3900.

4 6

Debugging help: bbtest-net gets http test timing wrong
by asparks＠doublesparks.net 23 Jul '08

23 Jul '08

Have a new install of Hobbit (4.2, tried 4.3 snap as well) on a fresh install of CentOS 4.6 x86_64, up to date on patches. I have a problem with HTTP tests on "random" web servers that I just can't figure out. I have about 64 of my hosts in the bb-hosts on this server, and have http tests defined for these servers. On most of these servers, Hobbit is reporting the "Seconds:" for the response at 3 seconds. It seems that it is inconsistent -- one cycle to the next, the 3-second response may move to a different set of servers. The http: tests are defined using the IP address of the server - no server name (so no DNS lookup). I've run a loop of tests on the same URL using wget and with curl, and used my browser and Telnet to connect to the same URL. I consistently get a response time of about 0.2 seconds maximum from the servers. The bbnet entry in hobbitlaunch.cfg looks like: CMD bbtest-net --report --ping --checkresponse --debug With the debugging turned on, I see the following entries periodically in the network test log: Address=10.1.5.17:80, open=1, res=0, err=0, connecttime=0.002965, totaltime=3.006810, Address=10.1.5.18:80, open=1, res=0, err=0, connecttime=0.002956, totaltime=3.007413, Address=10.1.24.67:80, open=1, res=0, err=0, connecttime=0.002860, totaltime=3.007120, The problem does not affect the same hosts each time. The problem will show a different number of hosts usually each cycle, sometimes on same servers, but often on different ones. I've tried the following to see if anything will help: * Reducing the number of hosts. If I only have a couple or three in the bb-hosts, the problem doesn't manifest. * Recompiling. Doesn't help. * Changing the test URL. Doesn't help. * Adding a --concurrency= option to the launch. If I use a concurrency of 1, the problem does not manifest. Setting the concurrency to 1 to fix the problem isn't an option, but makes me think something is getting really mixed up in the select() processing in bbnet. Does anyone have any ideas how to diagnose where Hobbit is coming up with a 3-second latency, when none of my test tools running off the same server can duplicate the same timing? Thanks for any ideas, this is really baffling me. -Alan

7 18