Xymon Mailing List Archive search

Xymonproxy on HA setup

4 messages in this thread

list Heather Keen · Wed, 7 Nov 2012 10:57:26 +0000 ·
Hi,

I have a xymonproxy running on a HA platform - two servers running HA and
providing virtual gateway IPs to a subnets beneath.  The xymon clients talk
to the xymonproxy on the virtual IPs, and thus the xymonproxy is only ever
running on one of the HA servers at any time.

My problem is, the xymonproxy reports two columns, xymonproxy and xymonnet,
 back to my main xymon server.  And that's fine for the active HA server,
but for the non active HA server those columns will go purple (assuming
that the HA does at some point fail over, so both servers will have
reported these columns at some time).

Does anyone have any idea how can I either: a) stop these columns from
being reported  OR  b) configure them not to go purple  ??

Heather
list Olivier Audry · Wed, 07 Nov 2012 14:10:48 +0100 ·
hello

here my setup :


server1 and server2 share a fs (gfs, drbd what you want) so we have the
xymon data replicated on both device at anytime.

HA hold the vip on the server1. The server1 run xymon and all your
monitoring tools. If the server1 goes down hw switch to server2 and
run xymon on server2. And you don't need xymonproxy.

hope that help

oau

Le mercredi 07 novembre 2012 à 11:51 +0000, Heather Keen a écrit :
Can't do that, and we don't want to have a secondary xymon server
there as this will very much complicate our alerting process.
list Heather Keen · Wed, 7 Nov 2012 13:17:16 +0000 ·
I use a proxy because we have many satellite sites (of which this is one of
them), all over the world. They all feed back to our main xymon server in
the UK.

For now I've fudged it, by creating an ext script that runs in the
xymon-client. If it sees that the xymonproxy process is not running then it
sends a clear for those tests, otherwise it does nothing.
quoted from Olivier Audry


On 7 November 2012 13:10, Olivier AUDRY <user-0dc286edb094@xymon.invalid> wrote:
hello

here my setup :


server1 and server2 share a fs (gfs, drbd what you want) so we have the
xymon data replicated on both device at anytime.

HA hold the vip on the server1. The server1 run xymon and all your
monitoring tools. If the server1 goes down hw switch to server2 and
run xymon on server2. And you don't need xymonproxy.

hope that help

oau

Le mercredi 07 novembre 2012 à 11:51 +0000, Heather Keen a écrit :
Can't do that, and we don't want to have a secondary xymon server
there as this will very much complicate our alerting process.
list Nicolas Lienard · Wed, 7 Nov 2012 19:17:31 +0100 ·
hi

we have also satellites in cluster in each country and they report through xymonproxy to a central cluster xymon.
The satellite acts as collector and report to the central. But they can be use isolated for a local view of the country.

For each satellite and for the central; the cluster solution uses Heartbeat and DRBD replication to have redundancy.

What is the purpose of checking xymonproxy. don t understand.

cheers
nico
quoted from Heather Keen


Le 7 nov. 2012 à 14:17, Heather Keen a écrit :
I use a proxy because we have many satellite sites (of which this is one of them), all over the world. They all feed back to our main xymon server in the UK.

For now I've fudged it, by creating an ext script that runs in the xymon-client. If it sees that the xymonproxy process is not running then it sends a clear for those tests, otherwise it does nothing.


On 7 November 2012 13:10, Olivier AUDRY <user-0dc286edb094@xymon.invalid> wrote:
hello

here my setup :


server1 and server2 share a fs (gfs, drbd what you want) so we have the
xymon data replicated on both device at anytime.

HA hold the vip on the server1. The server1 run xymon and all your
monitoring tools. If the server1 goes down hw switch to server2 and
run xymon on server2. And you don't need xymonproxy.

hope that help

oau

Le mercredi 07 novembre 2012 à 11:51 +0000, Heather Keen a écrit :
Can't do that, and we don't want to have a secondary xymon server
there as this will very much complicate our alerting process.