Here you will find out how to do some common questions raised with Xymon.
| Color | Recently changed | Last change > 24 hours |
|---|---|---|
| Green: Status is OK | | |
| Yellow: Warning | | |
| Red: Critical | | |
| Clear: No data | | |
| Purple: No report | | |
| Blue: Disabled | | |
Did you install a client ? The Xymon client package is installed automatically only on the Xymon server - on other systems, you must build the client package by running Xymon's configure-script with the "--client" option and build the client package on the hosts you want to monitor.
If you did install a client, then the two most probable causes for this are:
Add a CLIENT:clienthostname tag to the host entry in the hosts.cfg file, or re-configure the client to use the proper hostname.
They have been integrated into the Xymon network daemon. See the next three questions.
Use the command
~/server/bin/xymon 127.0.0.1 "drop HOSTNAME ftp"
to permanenly remove all traces of a test. Note that you need the quotes around the "drop HOSTNAME ftp".
First, remove the host from the ~/server/etc/hosts.cfg file. Then use the command
~/server/bin/xymon 127.0.0.1 "drop HOSTNAME"
to permanenly remove all traces of a host. Note that you need the quotes around the "drop HOSTNAME".
First, change the ~/server/etc/hosts.cfg file so it has the new name. Then to move your historical data over to the new name, run
~/server/bin/xymon 127.0.0.1 "rename OLDHOSTNAME NEWHOSTNAME"
Charles Jones provided this recipe on the Xymon mailing list:
From: Charles Jones Date: Sun, 06 Feb 2005 21:28:19 -0700 Subject: Re: [hobbit] Apache tag Okay, first you must make the indicated addition to your apache httpd.conf (or you can make a xymon.conf in apaches conf.d directory). [ed: See the hosts.cfg man-page for the "apache" description] Then, you must restart apache for the change to take effect (/etc/init.d/httpd restart). Then, manually test the server-stats url to make sure it's working, by using your browser and going to http://your.server.com/server-status?auto (you can also go to http://your.server.com/server-status/ to get some nice extended apache performance info). You should get back something like this: Total Accesses: 131577 Total kBytes: 796036 CPULoad: 1.0401 Uptime: 21595 ReqPerSec: 6.09294 BytesPerSec: 37746.7 BytesPerReq: 6195.16 BusyWorkers: 43 IdleWorkers: 13 Scoreboard: RR__RWR___RR_R_RR_RRRRRRRRR_RRRRRRR__RRR_RRRRCRRRRR_RRRR........................................................................................................................................................................................................ Now, assuming you are getting back the server-status info, time to make sure your hosts.cfg is correctly configured to collect and graph the data. Heres what I have in mine: 1.2.3.4 my.server.com # conn ssh http://1.2.3.4 apache=http://1.2.3.4/server-status?auto TRENDS:*,apache:apache|apache1|apache2|apache3 From what you said of your setup, I'm guessing your only problem is using the wrong url for the apache tag (you used "apache=http://192.168.1.25/xymon/" which just won't work - that's the kind of URL you would use for the http tag). Hope this helped. -Charles
There is a special document for this, describing how you can configure MRTG to save data in a format that Xymon can handle natively.
The ~/server/etc/tasks.cfg defines the update interval for all of the Xymon programs. The default is for network tests to run every 5 minutes, and webpage updates to happen once a minute.
Note that if you run the xymonnet-again.sh tool on your network test server (this is the default for a new Xymon server), then network tests that fail will run every minute for up to 30 minutes after the initial failure, so usually there is little need to change the update interval for your network tests.
Edit the file server/etc/graphs.cfg, and change the [temperature] definition from the default one to the one below that shows Fahrenheit graphs.
Configure your alerts in server/etc/alerts.cfg to use FORMAT=PLAIN instead of TEXT.
A common Apache configuration mistakenly believes any filename containing ".cgi" is a CGI-script, so it refuses to present the man-pages for the CGI scripts. Stephen Beaudry found the solution:
This occurs because by default, apache associates the cgi-script handler with any filename containing ".cgi". I fixed this on my server by changing the following line in my httpd.conf AddHandler cgi-script .cgi ->to-> AddHandler cgi-script .cgi$
Xymon by default uses the system mail command to send out messages. The mail-command in Solaris and HP-UX does not understand the "-s SUBJECT" syntax that Xymon uses. So you get mails with no subject. The solution is to change the MAIL setting in etc/xymonserver.cfg to use the mailx command instead. Xymon needs to be restarted after this change.
Not directly, but there is other Open Source software available that can handle SNMP traps. A very elegant method of feeding traps into Xymon has been described in this article by Andy Farrior.
Anything that can be automated via a script or a custom program can be added into Xymon. A lot of extension scripts are available for Big Brother at the www.deadcat.net archive, and these will typically work without modifications if you run them in Xymon. Sometimes a few minor tweaks are needed - the Xymon mailing list can help you if you don't know how to go about that.
But if you have something unique you need to test, writing an extension script is pretty simple. You need to figure out some things:
A simple client-side extension script looks like this:
#!/bin/sh
COLUMN=mytest # Name of the column
COLOR=green # By default, everything is OK
MSG="Bad stuff status"
# Do whatever you need to test for something
# As an example, go red if /tmp/badstuff exists.
if test -f /tmp/badstuff
then
COLOR=red
MSG="${MSG}
`cat /tmp/badstuff`
"
else
MSG="${MSG}
All is OK
"
fi
# Tell Xymon about it
$XYMON $XYMSRV "status $MACHINE.$COLUMN $COLOR `date`
${MSG}
"
exit 0
You will notice that some environment variables are pre-defined: XYMON, XYMSRV, MACHINE are all provided by Xymon when you run your script via xymonlaunch. Also note how the MSG variable is used to build the status message - it starts out with just the "Bad stuff status", then you add data to the message when we decided what the status is.
To run this, save your script in the ~xymon/client/ext/ directory (i.e. in the ext/ directory off where you installed the Xymon client), then add a new section to the ~xymon/client/etc/clientlaunch.cfg file like this:
[myscript] ENVFILE $XYMONCLIENTHOME/etc/xymonclient.cfg CMD $XYMONCLIENTHOME/ext/myscript.sh LOGFILE $XYMONCLIENTHOME/logs/myscript.log INTERVAL 5m
Server-side scripts look almost the same, but they will typically use the xymongrep utility to pick out hosts in the hosts.cfg file that have a special tag defined, and then send one status message for each of those hosts. Like this:
#!/bin/sh
HOSTTAG=foo # What we put in hosts.cfg to trigger this test
COLUMN=$HOSTTAG # Name of the column, often same as tag in hosts.cfg
$XYMONHOME/bin/xymongrep $HOSTTAG | while read L
do
set $L # To get one line of output from xymongrep
HOSTIP="$1"
MACHINEDOTS="$2"
MACHINE=`echo $2 | $SED -e's/\./,/g'`
COLOR=green
MSG="$HOSTTAG status for host $MACHINEDOTS"
#... do the test, perhaps modify COLOR and MSG
$XYMON $XYMSRV "status $MACHINE.$COLUMN $COLOR `date`
${MSG}
"
done
exit 0
Note that for server side tests, you need to loop over the list of hosts found in the hosts.cfg file, and send one status message for each host. Other than that, it is just like the client-side tests.
The menu system uses the CSS "hover" tag, but this is not supported on tablets and other touch-screen interfaces like the iPad. Mark Hinkle provides this solution to the problem:
In the ~xymon/server/etc/xymonmenu.cfg file, I added the
'<a href="javascript:;">' anchor around the top-level menu
items. Like:
<span class="menutag"><a href="javascript:;">Views</a><span class="invis">:</span></span>
If you cannot install any "foreign" tools on your system, then sending data to Xymon may be a challenge. But if you have access to either Perl, BASH or telnet on the system then it is possible.
Perl version:
#!/usr/bin/perl
#
sub sendToXymon {
use IO::Socket;
my($server,$port,$msg) = @_ ;
my $response;
my $sock = new IO::Socket::INET (
PeerAddr => $server,
PeerPort => $port,
Proto => 'tcp',
);
die "Could not create socket: $!\n" unless $sock;
print $sock $msg;
shutdown($sock, 1);
while ($response=<$sock>)
{
print "$response";
}
close($sock);
}
$host = $ARGV[0];
if ($#ARGV != 2) {
$port = 1984;
$msg = $ARGV[1];
}
else {
$port = $ARGV[1];
$msg = $ARGV[2];
}
sendToXymon($host, $port, $msg);
BASH version:
#!/bin/bash
#
HOST="$1" ; shift
if test $# -gt 1; then
PORT="$1"
shift
else
PORT="1984"
fi
MSG="$1"
exec 3<>/dev/tcp/$HOST/$PORT || exit 1
echo "$MSG" >&3
exit 0
Bourne / Korn shell (requires telnet):
#!/bin/sh
#
HOST="$1" ; shift
if test $# -gt 1; then
PORT="$1"
shift
else
PORT="1984"
fi
MSG="$1"
( echo "$MSG"; sleep 1 ) | telnet $HOST $PORT 2>&1 >/dev/null | grep -v "closed by foreign host"
Both of these take 2 or 3 parameters: The Xymon host (hostname or IP-address), optionally the portnumber (1984 by default if not specified), and the message that will be sent to Xymon. The Perl version will both send data to Xymon and print out any response that is sent back - the shell-versions can only be used to send data to Xymon.
Oyvind Bjorge provided the core of the Perl script, and Jeremy Laidman provided the core of the shell-scripts in this thread on the Xymon mailing list.