October 2009 - Xymon - Xymon mailman web

AUTO: Norbert Kriegenburg is out of the office (returning 14.10.2009)
by norbert.kriegenburg＠de.ibm.com 02 Oct '09

02 Oct '09

I am out of the office until 14.10.2009. Note: This is an automated response to your message "?Re: [hobbit] devmon stops working on non reachable device" sent on 2/10/09 0:18:13. This is the only notification you will receive while this person is away.

1 0

Antwort: Re: [hobbit] Graphing with broken numbers
by thorsten.erdmann＠daimler.com 01 Oct '09

01 Oct '09

First, sorry for the late response, I was on vacation. > What do you mean by "broken"? Do you mean non-integers? Yes, I mean non integer, e.g.: 22.3 deg or in german notation 22,3 °C > I am not sure what you are trying to depict here, are you meaning > that the DS names are Ambient______20 ? The output of 'rrdtool info > /path/to/temp.rrd |grep ^ds' or similar may help to illustrate more > accurately. I mean, that the rrd graphs show up a line for each integer that ever has occured. e.g. if I have an output line in the temperture test of "Ambient 20.5" I get a line named "Ambient_____20." in the rrd graph with the value 5. So rrd recognizes the string up to the colon as the name and the part after the colon as the value. So if now the temperature changes to 21.2 I get a new line in the rrd graph: Ambient_____20. with value 5 Ambient_____21. with value 2 > Which collector are you using? I have written the test by myself and it produces an output like the standard temperature test. I therefore use the standard temperature collector. This output works: Thu Oct 1 08:30:59 CEST 2009 Temperature Test on webtherm1 Warning level: 28 C Alarm level : 30 C Device Temp(C) Temp(F) ----------------------------------------- green Webtherm1 24 75 This output does not work: Thu Oct 1 08:30:59 CEST 2009 Temperature Test on webtherm1 Warning level: 28 C Alarm level : 30 C Device Temp(C) Temp(F) ----------------------------------------- green Webtherm1 24.5 75.5 If you are not the intended addressee, please inform us immediately that you have received this e-mail in error, and delete it. We thank you for your cooperation.

2 2

[hobbit] Load threasholds when bbwin in 'central' mode
by Craig_Whilding＠mentor.com 01 Oct '09

01 Oct '09

These weren't on separate pages per OS. I hadn't seen the CLASS values you can base rules on. Works great though as I can put the defaults back down for UNIX and set high windows class ones based on the percentage. Thanks, Craig ________________________________ From: John Thorton [mailto:xymon.user.ml at gmail.com] Sent: 29 September 2009 15:51 To: hobbit at hswn.dk Subject: Re: [hobbit] Load threasholds when bbwin in 'central' mode I don't use this setting myself, but BBWin.cfg has a configclass entry that defaults to "win32". You can use CLASS variables in hobbit-clients on the server to apply rules to clients based on that value. If win32 is too generic you can change it to, for example, win32_XXX. On Tue, Sep 29, 2009 at 9:21 AM, Iain M Conochie <iain at shihad.org> wrote: Whilding, Craig wrote: <snip> Is there a way to change the windows 'load' to be 'load percentage' or something so each type of box is using a different monitoring type? I know there were discussions about having UNIX boxes sending in a load percentage but that this was a difficult thing to achieve correctly. Our hostnames are normally dictated by service rather than platform unfortunately so I can't always just put so8/w2k etc pcre expressions in the thresholds to differentiate OS type. Do you have the windows servers on a different page to the UNIX / linux ones? You can use the PAGE statement for that. You may also be able to use it based on client but personally i have not used it Cheers Iain Regards, Craig Whilding To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

1 0

core dump
by vadud3＠gmail.com 01 Oct '09

01 Oct '09

I had a core dump with bb on non-global solaris 10 zone on T1000 bash-3.00# gdb ~hobbit/client/bin/bb core GNU gdb 6.6 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 "sparc-sun-solaris2.8"... Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libsocket.so.1...done. Loaded symbols for /lib/libsocket.so.1 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libc.so.1...done. Loaded symbols for /lib/libc.so.1 Reading symbols from /platform/sun4v/lib/libc_psr.so.1...done. Loaded symbols for /platform/SUNW,Sun-Fire-T1000/lib/libc_psr.so.1 Reading symbols from /lib/ld.so.1...done. Loaded symbols for /lib/ld.so.1 Core was generated by `/home/hobbit/client/bin/bb 0.0.0.0 @'. Program terminated with signal 11, Segmentation fault. #0 0xff109644 in doformat () from /lib/libc.so.1 (gdb) bt #0 0xff109644 in doformat () from /lib/libc.so.1 #1 0xff10ac90 in strftime () from /lib/libc.so.1 #2 0x00013594 in errprintf (fmt=0x1da28 "xmalloc: Out of memory!\n") at errormsg.c:47 #3 0x00013a28 in xmalloc (size=121384) at memory.c:121 #4 0x0001362c in errprintf (fmt=0x1da28 "xmalloc: Out of memory!\n") at errormsg.c:61 #5 0x00013a28 in xmalloc (size=121384) at memory.c:121 #6 0x0001362c in errprintf (fmt=0x1da28 "xmalloc: Out of memory!\n") at errormsg.c:61 #7 0x00013a28 in xmalloc (size=121384) at memory.c:121 #8 0x0001362c in errprintf (fmt=0x1da28 "xmalloc: Out of memory!\n") at errormsg.c:61 #9 0x00013a28 in xmalloc (size=121384) at memory.c:121 #10 0x0001362c in errprintf (fmt=0x1da28 "xmalloc: Out of memory!\n") at errormsg.c:61 #11 0x00013a28 in xmalloc (size=121384) at memory.c:121 #12 0x0001362c in errprintf (fmt=0x1da28 "xmalloc: Out of memory!\n") at errormsg.c:61 #13 0x00013a28 in xmalloc (size=121384) at memory.c:121 #14 0x0001362c in errprintf (fmt=0x1da28 "xmalloc: Out of memory!\n") at errormsg.c:61 #15 0x00013a28 in xmalloc (size=121384) at memory.c:121 ---Type <return> to continue, or q <return> to quit--- #16 0x0001362c in errprintf (fmt=0x1da28 "xmalloc: Out of memory!\n") at errormsg.c:61 #17 0x00013a28 in xmalloc (size=121384) at memory.c:121 #18 0x0001362c in errprintf (fmt=0x1da28 "xmalloc: Out of memory!\n") at errormsg.c:61 #19 0x00013a28 in xmalloc (size=121384) at memory.c:121 #20 0x0001362c in errprintf (fmt=0x1da28 "xmalloc: Out of memory!\n") at errormsg.c:61 #21 0x00013a28 in xmalloc (size=121384) at memory.c:121 #22 0x0001362c in errprintf (fmt=0x1da28 "xmalloc: Out of memory!\n") at errormsg.c:61 #23 0x00013a28 in xmalloc (size=121384) at memory.c:121 #24 0x0001362c in errprintf (fmt=0x1da28 "xmalloc: Out of memory!\n") at errormsg.c:61 #25 0x00013a28 in xmalloc (size=121384) at memory.c:121 #26 0x0001362c in errprintf (fmt=0x1da28 "xmalloc: Out of memory!\n") at errormsg.c:61 #27 0x00013a28 in xmalloc (size=121384) at memory.c:121 #28 0x0001362c in errprintf (fmt=0x1da48 "xrealloc: Out of memory!\n") at errormsg.c:61 #29 0x00013a68 in xrealloc (ptr=0x0, size=195584) at memory.c:151 #30 0x00017d80 in strbuf_addtobuffer (buf=0x302a0, newtext=0x51cc0 ' ' <repeats 34 times>, "(sparc) 2.6.0,REV=10.0.3.2004.12.15---Type <return> to continue, or q <return> to quit--- .20.59\n", newlen=76) at strfunc.c:109 #31 0x00012b44 in main (argc=3, argv=0xffbff51c) at bb.c:118 (gdb) Let me know if I should have sent the backtrace directly to Henrik instead. -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

1 0

[hobbit] Graphs stop update 24 hours after client reboot; start again 24 hours later - quick fix
by TRBrand＠cvs.com 01 Oct '09

01 Oct '09

> -----Original Message----- > From: Patrik Nilsson [mailto:patrik at jalbum.net] > Sent: Wednesday, September 30, 2009 9:51 AM > To: hobbit at hswn.dk > Subject: Re: [hobbit] Graphs stop update 24 hours after client reboot; > start again 24 hours later. > > Returning to this old thread as I ran into this issue today. > > Wed, 28 Jan 2009 12:23:17 +0000 (UTC), Henrik wrote: > >"Brand, Thomas R." <TRBrand (at) cvs.com> writes: > >>I need some help/suggestions to figure out why my "cpu load" and "users > >>& processes" graphs stop updating about 24 hours after the systems > >>reboot. The updates stop for anywhere from 12 to 24 hours, then simply > >>start back up again. > >>Only the "CPU load" and the "Users and Processes" graphs are having the > >>problem; disk, memory, cpu utilization, network traffic don't miss a > >>beat. > > >The only explanation I can come up with is that the format of > >some of the "cpu" status message is different for the first 24 hours > >after a reboot. > >Could you send me an example of the cpu status shortly after a reboot, > >and one when the graphs are working ? > >What OS are these boxes ? > > Running openSUSE 11.1 (x86_64). > > Client output that does not update the rrd: > > [top] > top - 14:39:44 up 1 day, 4:40, 3 users, load average: 2.42, 2.88, 2.89 > > Client output that does update the rrd: > > [top] > top - 14:42:51 up 40 days, 2:41, 3 users, load average: 4.19, 3.61, > 3.10 > > The only difference I can see is "day" instead of "days". > > Regards, > > Patrik > Based on Patrik's observation, I tried a few more things and found that 'top' does not appear to be the problem; however, on SuSE Linux 10.x 'uptime' also uses 'day' vs. 'days' and it is this value that causes the la.rrd graphs to lose the info. As a quick-fix, I have modified hobbitclient-linux.sh on my SuSE Linux 10.x systems as follows; echo "[uptime]" uptime | perl -pe "s/^(.*) day (.*)/\1 days \2/" The graphs updated on the next polling interval and started displaying the missing information. Thanks for pointing out the way Patrik :) Now if someone can figure out where and what needs to be updated in the source code -- that's a bit beyond my skills... Cheers Tom Brand

1 0

[hobbit] Real network service tests
by brian.daly＠criticalpath.net 01 Oct '09

01 Oct '09

Rob MacGregor wrote: > On Wed, Sep 30, 2009 at 15:58, Brian Daly <brian.daly at criticalpath.net> wrote: > >> The Man page for hobbit states that : >> >> When checking websites, it is possible to not only check that the webserver >> is responding, but also that the response looks correct by matching the >> response against a pre-defined pattern or a checksum >> >> Can anybody tell me how to configure this? I want to run a http test on a >> webserver. If the webserver does not return the response I am expecting then >> alert me that something has changed on the server. >> > > Under "HTTP tests" in the version of the man page I have it lists the > "cont=" test for doing content checks. > > Thanks for your reply Rob, Does anybody have an example of a HTTP test using the cont= test? Brian

1 1

Custom Purple Times
by pmeech＠gmail.com 01 Oct '09

01 Oct '09

Hi All, Firstly apologies if this is something I should have been able to locate on the mailing list; I've had a quick look but nothing appeared to answer it... I have an external test (shell script) that runs on my Xymon server (4.2.3), and logs into device web servers and gets a segment of HTML and performs some processing on it and sends to the xymon via the bb command. As there are 100 of these devices, I dont really want to be running this test every 10 minutes or so; and I also dont want to have 100 hosts going purple after 20 minutes. I realise I could call hobbitd with the --no-purple option; but purple is useful under many of the other tests. Is there a way of specifying no purple status on a per test basis? If I specify a hobbitlaunch time of greater than 20 minutes, would the test go purple waiting for hobbitlaunch to run the external again? Is there any other way that I could run this test once, every 4 hours and stop it going purple? As a last ditch resort I was considering storing the status messages (retrieved every 4 hours ideally via the shell script) in different files (per host) on the Xymon server and repeatedly sending this message every 10 minutes (hence preventing purple statuses). Although this would work, it doesnt seem a particularly clean method. Thanks for your time, Phil

2 2

Disk growth in MB during graphs timespan, anybody done it?
by Craig.Cook＠carquest.com 01 Oct '09

01 Oct '09

>Interested in showing delta/growth of filesystems, in MB, not % as is default. Someone must have done this by now... ok if it's just in the legend and not a line in graph. This way on my monthly reports >you get both visual as shown currently, but for the time span shown, the delta in MB is shown. It is built into xymon, just not shown by default. When you click on your disk graph your url will contain "service=disk" as part of it. Change it to say "service=disk1" If you want to change the units displayed eg. MB - not KB, you will need to edit hobbitgraph.cfg, CDEF for the disk1 definition. Craig

1 0

Somehow unexpected Hobbit behavior
by oliver_grube＠campbellsoup.com 01 Oct '09

01 Oct '09

Hello, I just want to share a issue we have seen the other day. I recently configured logrotate to rotate the hobbit logs in /var/log/hobbit (I know, it's XYmon, but we still run 4.2) These were the lines I used: --------------------------------------------------------- /var/log/hobbit/* { compress dateext maxage 60 rotate 1 missingok notifempty daily olddir /var/log/oldlog/hobbit create 640 root root sharedscripts postrotate /etc/init.d/hobbit restart endscript } --------------------------------------------------------- After the logrotate happened - midnight - I received hundreds of hobbit alerts - Ups - was the whole network down? I logged in and could reach the hobbit server - network works... But all (and only those) connection tests failed. Everything was red. A ping however show results and the traceroute reached the systems as well. The reason was simple. The Logrotate has re-created the hobbit log files - with 640 root root - as in the config. Hobbit however was not able to write into these files, as it runs as hobbit:users... My fault... Changing permission and of course the failure in logrotate, restart hobbit and everything becomes green again. I would have assumed, that hobbit simply decide not to start as it could not write to the logs... Or that the conn tests went clean due to this... This causes some calls this morning for the other guys on the alerting lists... ;-) mit freundlichen Grüßen - Best regards med vänlig hälsning - Met vriendelijke groeten Sincères salutations Oliver Grube Campbells Germany GmbH Registergericht Luebeck Reg. Nr. HRB 4082 Geschaeftsfuehrer: Joseph B. Folds III Geschaeftssitz: Geniner Strasse 88 - 100 23560 Luebeck Deutschland ********************************************************************** This e-mail and any files transmitted with it may contain confidential information and is intended solely for use by the individual to whom it is addressed. If you received this e-mail in error, please notify the sender, do not disclose its contents to others and delete it from your system. **********************************************************************

1 0