- Xymon - Xymon mailman web

user roles
by Ricardas.Vaitkus＠seb.lt 05 Mar '09

05 Mar '09

Hi all I have to design monitoring system, and there will be two main user groups who will use it: network administrators - their main need is to monitor the state of servers, and system monitoring team - their main need is to monitor the services runnig on those servers and some times they don't care about the state of server (if HDD is runnig out of space, load of cpu and so on). I wonder if there is any possibility to separate user roles on Hobbit or any work around for that. Thanks in advance, Ricardas

3 4

all hosts disappeared
by doctor＠makelofine.org 05 Mar '09

05 Mar '09

Hi, I tried to rename a host, according to it's new name : ~xymon/client/bin/bb 127.0.0.1 "rename OLD NEW" then after a refresh on xymon homepage, I can't see any of my host. I tried to restart xymon server, to undo my change (rename NEW OLD), but nothing changed. when I try to access the status of a unchanged host : https://BBDISP/xymon-cgi/bb-hostsvc.sh?HOST=ANOTHER_HOST&SERVICE=conn I get the following message : Status not available My filesystems are OK, and I can't see any error, in fact I know where to read xymon client logs, but not server logs... Thanks for your help, I'm scared :-(

2 2

BBWIN 64 Bit
by MFisher＠hra.com 05 Mar '09

05 Mar '09

Hi All, I have yet to find some useful docs that say whether or not BBWIN will work for 64bit machines... I have the clients configrued correctly and bb-hosts setup correctly but clients are not reporting and no ghost clients exist. Does it work on x64? Thanks.

7 18

Problem with Ghost Clients
by Jarrod.Hodder＠pmg.net.au 05 Mar '09

05 Mar '09

Hey Guys, Every few months I get the same problem. Each time I am on the webpage and I go to Reports >> Ghost Clients, I get the following error message. 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.8 (Ubuntu) Server at 192.168.10.22 Port 80 I had a look at my apache logs and the follow error is in there .: 34: Can't open /var/run/hobbit/bbdisp-runtime.cfg [Thu Mar 05 12:52:37 2009] [error] [client 192.168.10.85] Premature end of script headers: hobbit-ghosts.sh, referer: http://192.168.10.22/hobbit/ The ghost clients had worked before, but after a few months of use it just dies. I had a look for /var/run/hobbit/bbdisp-runtime.cfg but it doesn't exist. It looks like it never has, so I don't know how it could have run fine before without this file. This makes me think they are 2 different errors. My hobbit-ghosts.sh, file hasn't changed. I don't edit them. This is hobbit-ghosts.sh #!/bin/sh # This is the Hobbit wrapper for the ghosts CGI include () { . $1 ; } . /usr/lib/hobbit/server/etc/hobbitcgi.cfg . /usr/lib/hobbit/server/etc/hobbitserver.cfg export HOBBITMENU exec /usr/lib/hobbit/server/bin/hobbit-ghosts.cgi $CGI_GHOSTS_OPTS I cannot see any major problems in the Hobbit log files. What am I missing? Thanks Jarrod

1 0

ncv/splitncv question(s)
by hobbit＠general-failure.com 04 Mar '09

04 Mar '09

Hi, After creating custom graphs with NCV for our san's storage processor load I wanted to graph the read & write iops of our san on a per-lun basis. I hoped it could be done kind of dynamic (like disk) with NCV but that seems impossible. My san management station is spitting out nice status messages (using bbwincmd) formatted like this: <hobbit_display> status san lun,<lun#> green <timestamp> ReadIOPS : <#oips> WriteIOPS : <#iops> which result in numerous new columns under 'san' like "lun,11" "lun,12" etc (used the ",<#>" format since the 'disk' rrd's seem to use it). I was hoping they would all be 'hidden' in one 'lun' column (like disk) but that was wishfull thinking. Any solution/fix for this is welcome. Clicking one of these columns does show the correct results however (...although no graph since it doesn't even make rrd's). After reading about SPLITNCV in http://www.hswn.dk/hobbiton/2008/10/msg00423.html I could put something like SPLITNCV_lun="ReadIOPS:GAUGE,WriteIOPS:GAUGE" in my hobbitserver.cfg but if I understand correctly this would result in 2 rrd files lun.ReadIOPS.rrd and lun.WriteIOPS.rrd and that's not what I'm looking for. I'm hoping someone here "had fun" with something like this before and is able to point me in the right direction since I'm at the point that my head is about to explode. Thanks in advance, Wally

2 5

Issues with memory not reporting correctly
by wesley.townley＠unlv.edu 04 Mar '09

04 Mar '09

Using Hobbit Monitor 4.2.0 with Hobbit Client 4.2.0 ----- Memory report: Current status message follows: red Mon Mar 2 13:15:37 PST 2009 - Memory CRITICAL Memory Used Total Percentage red Physical 4294961768M 8192M 4294967229% green Swap 1600M 8191M 19% ----- from swap -s: total: 1616880k bytes allocated + 0k reserved = 1616880k used, 6771728k available ----- from vmstat 1 2 kthr memory page disk faults cpu r b w swap free re mf pi po fr de sr m8 m1 m1 rm in sy cs us sy id 0 0 0 29220552 14454688 35 111 61 1 1 0 0 1 1 1 -0 401 1512 1627 1 1 97 0 0 0 28939384 14052616 0 14 0 0 0 0 0 0 0 0 0 351 1128 1068 1 0 99 ---- How can I fix the issue with the physical memory? Thanks Wes

4 6

Bug
by bill.baker＠mfms.com 04 Mar '09

04 Mar '09

Version 4.2.2 On Xymon 4.2.2 running client on a redhat server( Red Hat Enterprise Linux AS release 4 (Nahant Update 6)), the script in bin called hobbitclient-linux.sh uses sed on the df -PL line (df -Pl -x none -x tmpfs -x shmfs -x unknown -x iso9660 | sed 's/Mounted on/Mounted-on/g' | column -t | sed -e '/^[^) to add a dash to the "Mounted on" line. This extra dash causes the server side to use the Filesystem name on the DISK line (hobbit-client.cfg) to control the warning level for a disk rather than the mount point name which is what the documentation says to use. Before removing the dash (I took the "sed 's/Mounted on/Mounted-on/g" out of the script), the following line in hobbit-client.cfg would not work "DISK /u 90 98", but the actual filesystem name would ("DISK /dev/mapper/VG00-lvu 90 98"). Confidentiality Notice: This is a transmission from a Winter Haven Hospital facility. This message and any attached documents may be confidential and contain information protected by state and federal medical privacy statutes. They are intended only for the use of the addressee. If you are not the intended recipient, any disclosure, copying, or distribution of this information is strictly prohibited. If you received this transmission in error, please accept our apologies and notify the sender. This Outbound Message has been scanned for Viruses and objectionable content by McAfee Secure Internet Gateway.

1 0

Xymon 4.3.0: Beta version available on Sourceforge
by henrik＠hswn.dk 04 Mar '09

04 Mar '09

So you didn't think I'd do two releases in one day, eh? I've uploaded the first beta version of xymon 4.3.0 to Sourceforge a few moments ago. If you have the time and a spare system to test it with, I'd appreciate any effort you can lend me in getting the bugs ironed out. You should be aware that there IS a lot of new stuff in this version, and I more or less expect it to crash spectacularly in your setup. So putting it on mission- critical systems could be seen as slightly dangerous. If you have looked at the "trunk" of the sourcecode repository, you will be familiar with the new stuff in this version. However if you compare it to what's in the current beta-release, you will notice that I have left out some of the more "dangerous" new components from this release. This was done to make testing a bit more manageable; I have a lot of new code for Xymon, and throwing all of it into one release would just wreak havoc on everyones systems. So instead I am preparing for a series of releases over the coming months, where new features will be introduced in a controlled fashion. But the current release is not void of new stuff. Far from it - here are the highlights of the 4.3.0 version: Core changes: * Hosts which appear on multiple pages in the web display can use any page they are on in the alerting rules and elsewhere. * Support for defining holidays as non-working days in alerts and SLA calculations. * Worker modules (RRD, client-data parsers etc) can operate on remote hosts from the hobbitd daemon, for load-sharing. * New API's for loadhosts and sendmessage, in preparation for the full 5.0 changes. * Always use getcurrenttime() instead of time(). * Various bugfixes collected over time. Network test changes: * Merged new network tests from trunk: SOAP-over-HTTP, SSL minimum cipher strength * Changed network test code to always report a validity period for network tests, so it it possible to run network tests less often than every 30 minutes (e.g. once an hour). * Make the content-type setting in HTTP POST tests configurable. * Make the source-address used for TCP tests configurable. * Make the acceptable HTTP result codes configurable. * Use and save HTTP session cookies. Web changes * "NOCOLUMNS" changed to work for all columns. * New "group-sorted" definition to auto-sort hosts in a group * Use browser tooltips for host comments * "Compact" status allows several statuses to appear as a single status on the overview webpages. * Trends page can select the time period to show. Buttons provided for the common selections. * Ghost list report now lists possible candidates for a ghost, based on IP-address or unqualified hostname. * Support generic drop-down lists in templates. Report changes * Number of outages as SLA parameter Miscellaneous * hobbitlaunch support for running tasks only on certain hosts, and for a maximum time. * Alert script get a unique ID for each alert. The plan for the future is to let this release stabilize for a month or so, depending on how many bugs show up. Then I'll introduce new releases about once every two months - with the following schedule (everything subject to change): Version 4.4: * SNMP support for data collection * Status updates based on data collected in the RRD files (this is really nice - essentially, *any* value you put into an RRD file can trigger a new or modified status in Xymon. So you could eg. change the status of your "http" test to go red, if the response time of a webpage exceeds 5 seconds). * Status "flap" handling, to catch statuses that change rapidly. Version 4.5: * Support for communication between clients and Xymon to use compression and/or encryption. * Support for client authentication via SSL certificates (so you cannot spoof a client message). Version 4.6: * Revised web interface - eliminate the need for webserver-based authentication, and provide more fine-grained authorization for the various Xymon components. * Per-user custom login pages, so the login will always show those systems that the user has responsibility for / is allowed to access. Somewhere along the road I will also introduce a new "ping" test daemon - I am getting to the point where ping'ing all hosts take longer than 5 minutes (I have a lot of hosts). So something needs to be done, and I think I know how to do it. Have fun! Henrik

19 34

Status change and history snapshots - how to force one?
by Vernon.Everett＠woodside.com.au 04 Mar '09

04 Mar '09

Greetings all Here is an interesting scenario, and I was wondering if there is a feature to cater for this. We are monitoring a system, and the alert went red. We acknowldeged the alert, and logged a call with our vendor for a replacement component. So far, all good. However, while waiting for the replacement component, we had another failure, which also should have triggered a red alert. (It's a disk array, with many many disks, and many hot spares, so it wasn't a tragic failure) The problem, of course, is that since the first alert was acknowledged, nobody spotted the second one, until the first disk was replaced, and the system remained red. (Somebody did the old "hmm, that's odd" and had a look.) Also, in the history, there is only one "snapshot" - when the first device failed. We have no history snapshot to show the second device failed. Is there a way to force a status update/change, even though there is no real colour change? Is there a way for Xymon to detect that we are looking at a second failure? If the answer to the above is no, then can we add this to the feature wish-list? I gave it a little thought, and came up with what I think is a simple implementation. We could add this an option to bb, similar to the [+lifetime] option, which will force the server to do a colour change from any colour to the new colour, even if they are the same. This should also clear any acks, and take a snapshot for the history. Implementing it as an option to bb, will probably require relatively minor changes at server level, and put the onus on the client scripts to decide what should force a change. But then again, I have no idea what is really involved in this, so feal free to ignore this paragraph. :-) Regards Vernon NOTICE: This email and any attachments are confidential. They may contain legally privileged information or copyright material. You must not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages and all attachments.

3 2

BBTEST_SOAP? What does it do?
by frank.gruellich＠navteq.com 04 Mar '09

04 Mar '09

Hi, while digging around on my own for an answer to http://www.hswn.dk/hobbiton/2009/03/msg00020.html I found BBTEST_SOAP in some source files. Unfortunately I could not find anything in the documentation regarding SOAP requests. What does it do? How does it work? What's the status of implementation? Thanks in advance. Kind regards, -- Navteq (DE) GmbH Frank Gruellich Map24 Systems and Networks Duesseldorfer Strasse 40a 65760 Eschborn Germany Phone: +49 6196 77756-414 Fax: +49 6196 77756-100 USt-ID-No.: DE 197947163 Managing Directors: Thomas Golob, Alexander Wiegand, Hans Pieter Gieszen, Martin Robert Stockman

2 2