February 2009 - Xymon - Xymon mailman web

Themeing for large displays
by bgmilne＠staff.telkomsa.net 11 Feb '09

11 Feb '09

We have some space available on a video wall, specifically a section of 18 panels (9 panels wide, 2 high), where each panel is 1400x1050, so a total size of 12600x2100. What I've done so far (since none of the interactive aspects of the Hobbit display are usable) is to make a frameset with the main view (50%), the critical systems view (30%), and a devmon weathermap (20%). The main view and the critical systems view are generated by an extra task running with bigger fonts and icon sizes. I am considering putting the non-green view on as well (in the same column as the critical systems view). However, there are still a number of problems: 1)I have gone as large as I can go with FONT tags and without CSS changes (it's a long time since I did any web development, and CSS was quite new then ...). 2)Some font sizes are hardcoded in the source code (e.g. event log on the bb2 page). While there is a MKBBACKFONT for the ack log (which I don't use), there is no MKBBLOGFONT. 3)The icons (at 64 pixels) are pixelating 4)The background images are too small (by over 3 *) I managed to take a photo of our section of the video wall, as it's difficult to get an idea of just how big it is: http://staff.telkomsa.net/~bgmilne/hobbit-videowall.jpg (I've made a lot of other changes as well since this, but I don't have a current photo now). I am prepared to try and fix some of these issues, e.g.: 1)Fix hardcoded fonts in source (e.g. use MKBBLOGFONT, or even MKBBACKFONT in the event log table) 2)Create some icon skins for various sizes (ideally in vector format in svn?) However, if any other people have similar problems/requirements, I wouldn't mind some assistance. However, I do want to try and fix some of this by today .. Regards, Buchan

3 2

Design Docoment help
by anthony.parackel＠bearingpoint.com 10 Feb '09

10 Feb '09

Hi All, I know this topic has been touched upon briefly before but I'd like to leverage hobbit at a client site and they require a formal monitoring design document. I was wondering if anybody has created something already. I'd like to put one together and share it with the rest of the group but it would be great if anybody could send me any useful information(diagrams, flow charts, etc). Thanks in advance, anthony *************************************************************************************************** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. ***************************************************************************************************

2 2

[hobbit] HA solutions
by gumby3203＠gmail.com 10 Feb '09

10 Feb '09

I know there was a thread on this a while back, and if I recall, there was mention that the 4.3.0 line would have features for HA. Anyway, I've been working on implementing a 2-node HA Xymon cluster using LinuxHA, and probably DRBD for shared disk (I have yet to implement DRBD, though). The Apache and Xymon services fail over to the other node fairly nicely, and I have successfully testing that using a shared IP to the Xymon web page works. It's still in the early stages of implementation and testing, but so far it appears hold hold promise. I'd be interesting in hearing about other HA solutions that have been implemented (if any). I don't recall previous mention of LinuxHA, so if no one else has done it, I'll be glad to update the list with my progress.

6 7

Various graphs not displaying in status column's after migration to new server
by craig.boyce＠rodney.govt.nz 10 Feb '09

10 Feb '09

Hi All, I had seen a mention of this or a very similar problem in another posting but there was no resolution mentioned that I could find. I have migrated hobbit and all data to a new server, Every thing is working fine except for some of the graphs are now not showing in the status column's. The disk, conn and memory graphs do not display in their respective status column's but they all are shown in the trends column and are being updated correctly. The la and netstat graphs are displayed in their status column's and the trend column correctly. Any idea's anyone? Is there are difference between the way the "disk, conn and memory" and "la and netstat" graphs / columns are generated or handled. Thanks Craig Boyce | Systems Engineer ICT | Information Management | Corporate Services Directorate p: 09 427 3187 | m: 0274 724 797 | e: craig.boyce at rodney.govt.nz Rodney District Council | 50 Centreway Road | Private Bag 500 | Orewa 0946 | New Zealand p: 0800 426 5169 | f: 09 426 7280 | www.rodney.govt.nz P Please consider the environment before printing this email. DISCLAIMER: The information contained in this email message is confidential and for the attention of the intended recipient only. It is not necessarily the official view or communication of the Rodney District Council. If you are not the intended recipient you must not disclose, copy or distribute this message or the information in it. If you have received this message in error, please delete or destroy all copies of the email and notify the sender immediately. Rodney District Council accepts no responsibility for any effects this email message or attachments has on the recipient network or computer system.

1 0

RHEL5 and status-board not available bug?
by flyzone＠technologist.com 10 Feb '09

10 Feb '09

Well...We think it's a big bug, where 'we' is me and RedHat support. Of course I'm speaking of Linux and not about the Solaris bug, and my kernel parameter are ok. I moved from a rhel4.5 with kernel 2.6.9-55 to a rhel5.3 with kernel 2.6.18-128 with bonding (active-passive) gigabit ethernet, and nfs files storing the xymon data in a Veritas cluster. The xymon server get 3000 hosts and about 17093 status messages. The problem is...the timeout, the hobbit status page go in green, the pages sometimes are slow to be read or give a "Status not available" Speaking with Redhat premium support, I sent them a trace of the error (about 40MB gzip...) and for them the cause is a bug in the thread management cause in the RHEL5 is not more possible to use the old POSIX implementation of threading, but needs to use just the Linux Threading "version". Of course I have lost some of the sentences....sorry but I'm not a programmer. They avoid at all a problem with the nfs share, the throughput of xymon is about a stable 30KB/s, while network test indicate a possibility of 50-78MB/s. However I had to modify the mount option to avoid many setattr calls. As a workaround I have modify the sendmessage call in lib folder adding to repeat the send of message: if (res == BB_ETIMEOUT) { usleep(5); res = sendtomany((recipient ? recipient : bbdisp), xgetenv("BBDISPLAYS"), msg, respfd, respstr, fullresponse, timeout); } This of course increase the busy time but doesn't get again an "all system green" problem. I'm running a xymon 4.2.0 with allinonepatch and xymon 4.2.2 doesn't seem to have any changes in this problem however I'll try in the next days. Other issue...shutting down xymon I always need to clear all with ipcrm cause segments are yet present. Nothing more in logs, just the status-board not available. If someone already got this issue (doesn't seem in the past posts) please give me a tip.... Ah..here my kernel parameter: ------ Shared Memory Limits -------- max number of segments = 8192 max seg size (kbytes) = 67108864 max total shared memory (kbytes) = 17179869184 min seg size (bytes) = 1 ------ Semaphore Limits -------- max number of arrays = 128 max semaphores per array = 250 max semaphores system wide = 32000 max ops per semop call = 100 semaphore max value = 32767 ------ Messages: Limits -------- max queues system wide = 16 max size of message (bytes) = 65536 default max size of queue (bytes) = 65536 Thanks in advance. -- Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com

2 1

[hobbit] hobbit-alerts.cfg: behaviour of TIME and DURATION together
by henrik＠hswn.dk 10 Feb '09

10 Feb '09

In <1233173020 at mknews.sslug.dk> "SebA" <spa at syntec.co.uk> writes: >Bizarrely and somewhat contradictory to the behaviour below is the behaviour >of DURATION well inside of the times specified with the TIME rule. Is >DURATION not reset when the colour of the alert changes??? That seems to be >the only explanation for what I'm seeing (though it is early days to be >certain). Or, to put it another way, is DURATION the non-green DURATION, >rather than the duration of being in a certain colour? You are correct - DURATION is the time the status has been in a "potentially alerting state", i.e. yellow, red or purple. >The config I currently have is: > >$pg-sebsms=me AT mysms2emailprovider.com TIME=W:0845:2355 > >HOST=DbR1 SERVICE=Special > MAIL me AT work.co.uk COLOR=red DURATION>2 REPEAT=30 RECOVERED > MAIL $pg-sebsms COLOR=red DURATION>15 REPEAT=300 RECOVERED > >I was hoping (and expecting) the above rules to only alert after 2 minutes >and 15 minutes repectively of being red, given that COLOR=red is part of the >rule. I do, however, acknowledge that there may be (rare) cases where you >would want to include the yellow time in the DURATION. In which case, we >really need REDDURATION, YELLOWDURATION and PURPLEDURATION rules. Or >perhaps just a way of specifying how you want the DURATION to be calculated >in that rule: DURATIONTYPE=<NONGREEN|LASTCHANGE> (that's either or). Or >even more powerfully: DURATIONCALC=color[,color] (adds up the duration of >being in these colour states). (However, this could become resource >intensive if you specify DURATIONCALC=red,yellow,purple,green or something! >On the other hand, one only needs to check back as far as DURATION, rather >than calculate the total time in these colour states.) I agree that the way it works currently is not entirely what you would expect from the rules you have. What would probably be best was for Xymon to calculate the duration based on the COLOR-settings defined for the alert (so for your rules, it would mean the alert triggered 2 respectively 15 minutes after the status went red - and yellow-time was ignored). The problem with that approach is that it breaks down when a status wobbles between yellow and red - e.g. a disk that is filled to just around the critical level: You could end up in a situation where you wouldn't get any alerts because it didn't stay red long enough to exceed the color- specific DOWNTIME setting. But it would probably make more sense than the current modus operandi. I'll see what I can do about that. Regards, Henrik

2 1

Hobbit 4.3.0 Observations
by rsmrcina＠wi.rr.com 10 Feb '09

10 Feb '09

Compiles clean on SLES 10 SP1. A number of the web pages (eg non-green view, several report pages) display 'link bb_footer' on the bottom. The Config report and Ghost report get a 500 web server error. They want to open up an editor to display the shell script. When I open it, I see the 500 error. -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009

3 2

Email alerts config
by JEloff＠media24.com 10 Feb '09

10 Feb '09

Hi Might be a stupid question for all you clever guys but I need to change the "from" address that hobbit sends it's mails from and also the link in the bottom of the mail that can be clicked on. Can anybody tell me where to do this? Thanks in advance ------------------------------------------------------------------------------------ This email and its contents are subject to an email legal notice that can be viewed at: http://www.naspers.com/email/disclaimer.html. Should you be unable to access the link provided, please email us for a copy at Helpdesk at Media24.com. Hierdie e-pos en sy inhoud is onderhewig aan 'n regskennisgewing oor elektroniese pos wat gelees kan word by http://www.naspers.com/epos/vrywaring.html. 'n Afskrif kan aangevra word by Helpdesk at Media24.com. ------------------------------------------------------------------------------------

2 1

[hobbit] [trunk] coredump on hobbitfetch
by gatis.anee＠gmail.com 10 Feb '09

10 Feb '09

Is there any suspicion what is the reason for hobbitfetch crash? This is how often hobbitfetch crashes on my server (I have 16 hosts with pulldata tag): Tue Feb 10 16:46:22 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 16:11:11 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 16:11:11 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 16:00:35 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 15:20:08 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 14:15:57 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 13:51:04 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 13:45:50 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 13:34:59 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 13:24:58 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 13:24:58 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 13:23:47 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 13:13:45 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 13:08:59 2009 xymon-server hobbitfetch unknown From -> To red Tue Feb 10 11:03:22 2009 xymon-server hobbitfetch unknown From -> To red just another backtrace: Core was generated by `/home/hob/xymon/server/bin/hobbitfetch --server=xxx.xxx.xxx.xxx --no-daemon --pid'. Program terminated with signal 6, Aborted. #0 0x0095b402 in __kernel_vsyscall () (gdb) backtrace #0 0x0095b402 in __kernel_vsyscall () #1 0x00501d10 in raise () from /lib/libc.so.6 #2 0x00503621 in abort () from /lib/libc.so.6 #3 0x08050ff3 in sigsegv_handler (signum=11) at sig.c:57 #4 <signal handler called> #5 main (argc=4, argv=Cannot access memory at address 0x4 ) at hobbitfetch.c:709 (gdb) On Thu, Jan 29, 2009 at 9:32 AM, Olivier Beau <obeau79 at gmail.com> wrote: > > here's the backtrace > > # gdb /data/hobbit/server/bin/hobbitfetch core > GNU gdb 6.4.90-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > > warning: Can't read pathname for load map: Input/output error. > Reading symbols from /usr/lib/libz.so.1...done. > Loaded symbols for /usr/lib/libz.so.1 > Reading symbols from /lib/tls/i686/cmov/libc.so.6...done. > Loaded symbols for /lib/tls/i686/cmov/libc.so.6 > Reading symbols from /lib/ld-linux.so.2...done. > Loaded symbols for /lib/ld-linux.so.2 > Core was generated by `/data/hobbit/server/bin/hobbitfetch --server=127.0.0.1 --no-daemon --pidfile=/d'. > Program terminated with signal 6, Aborted. > #0 0x0804ae65 in main (argc=6, argv=Cannot access memory at address 0x4 > ) at hobbitfetch.c:748 > 748 switch (connwalk->action) { > (gdb) bt > #0 0x0804ae65 in main (argc=6, argv=Cannot access memory at address 0x4 > ) at hobbitfetch.c:748 > (gdb) > > > > > On 28/01/2009 22:20, Henrik Størner wrote: >> >> In <49805E29.6050204 at gmail.com> Olivier Beau <obeau79 at gmail.com> writes: >> >>> In top, i see that hobbitfetch in at 100% cpu >>> (i'm only doing pulldata on less that 10 hosts) >> >>> Is there a special signal i should send to hobbitfetch ? >>> or should i just do a kill -9 on it ?.. >> >> "kill -6" causes it to dump core, which might be interesting. >> It's a different bug from the crash, though (and it's been reported >> before, but I cannot seem to get a handle on what triggers it). >> >> >> Regards, >> Henrik >> >> >> 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 > >

1 0

[hobbit] hobbitd_rrd crash in trunk
by obeau79＠gmail.com 10 Feb '09

10 Feb '09

Hello Henrik, I upgraded to 1.2.30 and started disabling some status, and after a few hours, got a crash last log is again a disabled status: 2009-02-02 17:47:46 hobbitd_rrd: Got message 812317 @@status#812317/www-vip-topannonce|1233593260.660693| 127.0.0.1||www-vip-test|http|2147483647|blue||blue|1233592711|0||-1|Disabled by 2009-02-02 17:47:46 startpos 211966, fillpos 227847, endpos -1 2009-02-02 17:47:46 Peer at 0.0.0.0:0 failed: Broken pipe 2009-02-02 17:47:46 Peer not up, flushing message queue Olivier On 30/01/2009 17:27, Henrik Størner wrote: > Hi Olivier, > > just one quick question: What version of the RRDtool library are you using ? > > I just had a rather nasty problem which looks like a problem with the RRD > library on Debian (1.2.15); upgrading to 1.2.30 - the latest 1.2.x version - > made the problem disappear. This was causing random crashes of hobbitd_rrd ... > > > > Regards, > Henrik > > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > >

5 6