October 2006 - Xymon - Xymon mailman web

force client checks from server ?
by stephane.caminade＠ias.u-psud.fr 20 Oct '06

20 Oct '06

Hi, I was wondering if there is a possibility to force some kind of client refresh from the hobbit server. For instance, a network problem occurs, and as soon as you have corrected it, you want to check the state of the monitored clients, without allowing for the 5mins delay (by default). Regards, Stephane -- _____________________________________________________________________________ Stephane Caminade Administrateur Systemes et Reseaux \ <Stephane.Caminade at ias.u-psud.fr> Institut d'Astrophysique Spatiale / tel : (33) (1) 69 85 87 03 Batiment 121, Universite Paris XI \ fax : (33) (1) 69 85 86 75 F-91405 ORSAY Cedex / www : http://www.ias.u-psud.fr/ _____________________________________________________________________________

3 3

hobbit alerting on PAGE in dispinclude file
by gendalia＠iastate.edu 20 Oct '06

20 Oct '06

I have what I call "personal pages" for my co-workers that I have set up in a dispinclude file. It would be very simple to set up alerts for those people using the PAGE matching their personal pages, but in the version of Hobbit I'm using (4.1.2), alerting doesn't seem to work on the pages that are in a dispincluded file. Should they? Do they in later versions? Tracy J. Di Marco White Information Technology Services Iowa State University

1 0

Email alert based on specific process
by tmelcher＠saionline.com 20 Oct '06

20 Oct '06

Does anyone know if this ever got implemented, I was scanning through a thread back in Nov 2005? I need something similar based on ports, if a specific port is down I need a specific group notified. Referenced Post: http://www.hswn.dk/hobbiton/2005/11/msg00170.html Thanks Trent Trent Melcher Unix/Linux Systems Administrator Securities America Financial Corporation (402) 399-9111 x2774 tmelcher at saionline.com Securities America, Inc., a Registered Broker/Dealer, Member NASD/SIPC. Advisory services offered through Securities America Advisors, Inc., an SEC Registered Investment Advisory The text of this communication is confidential, and use by any person who is not the intended recipient is prohibited. Any person who receives this communication in error is requested to immediately destroy the text of this communication without copying or further dissemination. Your cooperation is appreciated.

3 2

Reducing time in port monitoring
by tmelcher＠saionline.com 20 Oct '06

20 Oct '06

I need to monitor port 8888 on one of my servers. Currently I have this setup and working fine. What I need to do is redurce the time to every minute. Im guessing I need to drop the INTERVAL down on the client to 1m so it send the client file to the hobbit server every minute. What do I need to change on the Hobbit server to read the clients data every minute for the port stats? Is it as simple as adding the port:60 to the servers entry in the bb-hosts file? Thanks Trent Trent Melcher Unix/Linux Systems Administrator Securities America Financial Corporation (402) 399-9111 x2774 tmelcher at saionline.com Securities America, Inc., a Registered Broker/Dealer, Member NASD/SIPC. Advisory services offered through Securities America Advisors, Inc., an SEC Registered Investment Advisory The text of this communication is confidential, and use by any person who is not the intended recipient is prohibited. Any person who receives this communication in error is requested to immediately destroy the text of this communication without copying or further dissemination. Your cooperation is appreciated.

2 1

Packaging Hobbit 4.2.0
by paul.moore＠verizonbusiness.com 19 Oct '06

19 Oct '06

I've been working for several weeks trying to build a precompiled pkg of hobbit for solaris and have had varied success. After a great deal of troubleshooting I stumbled across a fundamental flaw as best that I can tell. It appears that several of the binaries (bb, hobbitd, hobbit-ghosts.cg to name a few) compiled actually have the local server and ip as configured in the Makefile rather than calling the hobbitserver.cfg file for that information. Is this by design? And if so, has anybody tried and successfully built a Solaris pkg? Paul Moore V966-5159 MSO OSS Support -=-=-=-=-= Pinky, Are You Pondering What I'm Pondering? Well, I think so Brain but if Jimmy cracks corn and no one cares, why does he keep doing it?

4 3

[hobbit] format for CPU data?
by Thomas.Kern＠hq.doe.gov 19 Oct '06

19 Oct '06

For the number of REAL users on my z/VM systems, the cpu load of this monitoring should not be bad. And I can always try compiling the REXX code and EXECLOADing all of the pieces. /Thomas Kern /301-903-2211 > -----Original Message----- > From: Rich Smrcina [mailto:rsmrcina at wi.rr.com] > Sent: Thursday, October 19, 2006 12:21 PM > To: hobbit at hswn.dk > Subject: Re: [hobbit] format for CPU data? > > > The TTY idea makes alot of sense. Hopefully chasing down the last > command isn't too much work (for the CPU that is), the one thing you > don't want is for your network service monitoring to become a > performance problem... :) >

2 1

[hobbit] format for CPU data?
by Thomas.Kern＠hq.doe.gov 19 Oct '06

19 Oct '06

I will look at reworking the PROCS data to match 'ps -ef'. The user/procs count used to be obtained by bigbrother from the messages in the CPU test. CMD is irrelevant for most of the PROCS (service virtual machines) on z/VM, but for a real user, we could get the last command buffer. TTY could be filled in with the LUNAME, terminal device number or 'DISC' to be meaningful. /Thomas Kern /301-903-2211 > -----Original Message----- > From: Rich Smrcina [mailto:rsmrcina at wi.rr.com] > Sent: Thursday, October 19, 2006 11:56 AM > To: hobbit at hswn.dk > Subject: Re: [hobbit] format for CPU data? > > > Then for procs you may need to present that data is 'ps -ef' format: > > UID PID PPID C STIME TTY TIME CMD > root 1 0 0 Oct18 ? 00:00:01 init [5] > root 2 1 0 Oct18 ? 00:00:00 [ksoftirqd/0] > root 3 1 0 Oct18 ? 00:00:00 [events/0] > root 4 1 0 Oct18 ? 00:00:00 [khelper] > root 9 1 0 Oct18 ? 00:00:00 [kthread] > root 19 9 0 Oct18 ? 00:00:08 [kacpid] > root 116 9 0 Oct18 ? 00:00:00 [kblockd/0] > root 156 9 0 Oct18 ? 00:00:00 [pdflush] > > Some of the data here doesn't really apply to z/VM, but it should be > possible to come up with some sort of value for each column. UID and > CMD would probably be the same thing, PID can be a counter, > PPID would > be 1, STIME would be the logon date or time, TTY is not relevant and > TIME would be the CPUTime. >

2 1

[hobbit] Re: format for CPU data?
by Thomas.Kern＠hq.doe.gov 19 Oct '06

19 Oct '06

I have no direct control over the hobbit server, but will forward this to that sysadmin. /Thomas Kern /301-903-2211 > -----Original Message----- > From: Charles Goyard [mailto:cgoyard at cvf.fr] > Sent: Thursday, October 19, 2006 12:17 PM > To: hobbit at hswn.dk > Subject: Re: [hobbit] Re: format for CPU data? > > > Kern, Thomas a écrit : > > I just looked at the Hobbit server and it isn't plotting > the cpu data > > either but the same format message is getting plotted by > bigbrother. I > > need to break open that hobbit_rrd to find the parsing for these > > 'STANDARD' tests. > > It can be that you have a rogue $HOBBITHOME/data/host/cpu.rrd > with wrong DS. If so try to remove that file. > > -- > Charles Goyard - cgoyard at cvf.fr - (+33) 1 45 38 01 31

1 0

[hobbit] Re: format for CPU data?
by Thomas.Kern＠hq.doe.gov 19 Oct '06

19 Oct '06

I just looked at the Hobbit server and it isn't plotting the cpu data either but the same format message is getting plotted by bigbrother. I need to break open that hobbit_rrd to find the parsing for these 'STANDARD' tests. /Thomas Kern /301-903-2211 > -----Original Message----- > From: news [mailto:news at sea.gmane.org] On Behalf Of Mike > Sent: Thursday, October 19, 2006 11:57 AM > To: hobbit at hswn.dk > Subject: [hobbit] Re: format for CPU data? > > I get the status messages using the format 'status > host-with-commas.test color message'. > I want the CPU load averages to be graphed. Thank you for > your format above, > I cannot get hobbitd to graph the data using that format. > > Mike

2 1

[hobbit] Sending data from script to an rrd
by Thomas.Kern＠hq.doe.gov 19 Oct '06

19 Oct '06

So for those of us on Non-Linux systems, the hobbit_rrd source code has all of the parsing definitions for the 'standard' tests. If I want to present 'standard' data to hobbit to be reported AND graphed, it must fit the parsing as defined in hobbit_rrd. If I want to present NEW data, I create a new column with a single extension script on the hobbit server to parse the new data delivered by the clients. /Thomas Kern /301-903-2211 > -----Original Message----- > From: henrik at hswn.dk [mailto:henrik at hswn.dk] > Sent: Wednesday, October 18, 2006 5:25 PM > To: hobbit at hswn.dk > Subject: Re: [hobbit] Sending data from script to an rrd > > ... Snipped ... > When the Hobbit server - specifically, the "hobbitd" process that > receives messages from the network - gets your data via a "status" > message, it creates a column with the color your script decided upon. > But it doesn't do any analysis of the data. Instead, it just > shoves the > raw message out through one or more of the Hobbit "channels", and lets > the hobbitd_* worker modules do whatever they want to do with it. > One of these worker modules is "hobbitd_rrd", which (as the name > implies) handles updating of RRD files. It has to pick out the > interesting numbers from the raw status message, and put them into an > RRD file. hobbitd_rrd knows how to handle several different kinds of > status messages (cpu, disk, memory, network response times > ...), but for > custom tests that you write yourself, you'll have to provide the code > to pick out those numbers you want to put into the graph. So this is > where the second script comes into play: This script is the > one with the > "echo" statements that you cannot quite figure out how should work. > Basically, whenever hobbitd_rrd sees a status message which is one of > those listed in the "--extra-tests" option, then it hands over the > parsing of the status message data to a script you've written. This > script must then return the data that should go into the RRD file. >

4 7