Randall
I have much the same setup as you have suggested, although they are both
considered production, rather than one being "pre-prod". Essentially, both
Xymon servers operate completely independently of each other, so if either
server goes down, the other server continues to receive all of the client
updates and do all of the probes.
I have all of the configuration committed to a subversion server. So I can
make a change on one Xymon server, test it, commit it and then "svn update"
on the other server to pull in the change. All configuration files between
the two servers are identical, with the exception of a few variables in
xymonserver.cfg. So what I do is create myself a file
xymonserver-local.cfg, and include it near the top of xymonserver.cfg. In
the "-local" version of the file, I define XYMONSERVERHOSTNAME,
XYMONSERVERIP and XYMONSERVERS to be the name and address of that Xymon
server. You should remove any of these definitions from the main
xymonserver.cfg and add the following line near the top:
include /etc/xymon/xymonserver-local.cfg
Both of my servers have every client host listed in the replicated
hosts.cfg. So each Xymon server independently pings and tests each host in
its network checks. In each of the clients hosts, I list both server IPs
in XYMONSERVERS, so that both servers get client messages from the client,
and status messages from any ext scripts they might happen to run.
One shortcoming with what I've described is that disabling or enabling a
server will only apply to the Xymon server where that update takes place.
But there's a simple way to have these changes propagate to both servers.
First, create another file called xymonserver-enadis.cfg, containing the
following:
include /etc/xymon/xymonserver.cfg
XYMSERVERS="10.1.1.1 10.2.2.2"
In this file, list the IPs of both Xymon servers in XYMSERVERS. Now,
update cgioptions.cfg and set:
XYMONENV_ENADIS=/usr/lib/xymon/server/etc/xymonserver-enadis.cfg
Now, when you disable a host, this will run xymonserver-enadis.cfg but have
it pull its config from the special "-enadis" file, complete with the
XYMSERVERS parameter listing both IP addresses. So disabling a host on any
one Xymon server causes the disable message to be sent to both servers.
There's one thing to watch out for with this setup, is when you're testing
changes to client-local.cfg made to only one of the Xymon servers. When
each client sends it client data, it is also given its section of
client-local.cfg to process. If the client sends client data to two Xymon
servers, it's the client-local.cfg section from the second Xymon server
that will be used, and any "test" changes to that file on the first server
will be ignored.
Also, check out the WikiBook "HA" section for some other options:
https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Guide#Hobbit_in_HA
Cheers
Jeremy
On Wed, Dec 16, 2015 at 9:11 AM Randall Badilla Castro <
user-911f8b61a6eb@xymon.invalid> wrote:
Hi:
The new site administrator has been happy with the simplicity and
usability of Xymon.
Then have asked for more changes over our actual config.
Currently I have one (kind of resource limited) Sparc V210 as xymon
server. But have find out then sometimes the apache or xymond process
coredump by some mistakes or changes. Sometimes we notice when this
happen so just restart the process or server. But when the problem
arises and we don't notice the problem; after 8 hours there is a lot of
rrd data that can't be showed. (We can't send sms or emails out of the
site domain).
So my boss have asked to make an another xymon server; to workout
changes on one and keep the other with the older config till the new
changes are "stable".
I have read the HA section but I'm unsure that can justify a cluster. So
my question is if I have two xymon servers with the same config and tell
the clients that report to both of them; can this scenario accomplish
the task ?
I think that my boss is requesting a kind of pre-production/ production
config. So I though two same config servers fit the scenario or must use
the cluster ??
Any input is welcome!
Thanks a lot!
--
CONFIDENCIALIDAD - La información contenida en este mensaje es confidencial
y se dirige únicamente a su destinatario. Si usted lector de este mensaje
no es ese destinatario, la diseminación, distribución o copia del mismo o
sus adjuntos (de existir) se encuentran prohibidos. Si lo ha recibido por
error, por favor notifique de manera inmediata por correo y destruya las
copias de su correo.
CONFIDENTIALITY STATEMENT - The information contained in this message is
confidential and intended only for the addressee. If the reader of this
message is not the intended recipient you are notified that any
dissemination, distribution or copy of this message and attachments (if
any) is strictly prohibited. If you have received this in error, please
immediately notify us by reply email, destroy all copies and remove from
all media.