routing between xymons
list Ron Cohen
Hello there... we have here a pretty big production environments, and even bigger non-production. I've configured xymon for both, but the guys that do the actual monitoring objected to have alerts coming from non-production servers, since those are mostly non-crucial - they don't want to see any of those reds on their screens. I played for some time with the alert propagating, but it won't do, so sadly I disabled all the non-prod clients. The obvious solution (unless there's a simpler one) is to start another xymon on different port and different URL. the problem is that it requires a firewall setting, which is a major headache to make. what i thought of, is to do routing at the bb port, so incoming clients will be routed according to the IP origin to the prod and non-prod xymond (say ports 1985 & 1986). It is not difficult to implement, but before pythonizing it, i wonder if there is an existing solution within xymon which i missed, or anyone else already done it? many thanks _rony
list Robert Schetterer
Am 13.05.2016 um 17:13 schrieb Ron Cohen:
▸
Hello there... we have here a pretty big production environments, and even bigger non-production. I've configured xymon for both, but the guys that do the actual monitoring objected to have alerts coming from non-production servers, since those are mostly non-crucial - they don't want to see any of those reds on their screens.
why not NOCOLUMNS:column[,column] for testing stuff https://www.xymon.com/help/manpages/man5/hosts.cfg.5.html NOCOLUMNS:column[,column] Used to drop certain of the status columns generated by the Xymon client. column is one of cpu, disk, files, memory, msgs, ports, procs. This setting stops these columns from being updated for the host. Note: If the columns already exist, you must use the xymon(1) utility to drop them, or they will go purple.
▸
I played for some time with the alert propagating, but it won't do, so sadly I disabled all the non-prod clients. The obvious solution (unless there's a simpler one) is to start another xymon on different port and different URL. the problem is that it requires a firewall setting, which is a major headache to make. what i thought of, is to do routing at the bb port, so incoming clients will be routed according to the IP origin to the prod and non-prod xymond (say ports 1985 & 1986). It is not difficult to implement, but before pythonizing it, i wonder if there is an existing solution within xymon which i missed, or anyone else already done it? many thanks _rony
Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
list John Thurston
▸
On 5/13/2016 7:13 AM, Ron Cohen wrote:
Hello there... we have here a pretty big production environments, and even bigger non-production. I've configured xymon for both, but the guys that do the actual monitoring objected to have alerts coming from non-production servers, since those are mostly non-crucial - they don't want to see any of those reds on their screens.
One way that comes to mind is using the "nopropyellow" (etc) tags on the hosts. We mix our production and test hosts on pages, but mark the test hosts not to propagate their alerts upward. Their test results appear on their own page, but not on their parent page. Also look into the "nonongreen" tag.
Note: the tags mentioned above affect the generation and display of the web pages. They do no affect alerts or the behavior of xymondboard.
--
Do things because you should, not just because you can.
John Thurston XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Enterprise Technology Services
Department of Administration
State of Alaska
list Ron Cohen
Thanks for the suggestions guys, however: The monitoring team use the non-green page for the monitoring. This page includes all alerts, whether propagated or not. Also, I can't hide the non-production alerts, since those should be acted upon by other support teams, which will also use the non-green as their main monitor. I'm not using the Critical view, since the alerts scripts (and the analysis.conf, using the TEXT property) generate URLs to specific expert advice for the monitoring team, so they can assign an incident to the appropriate groups. Also, as per the above, what's required is separating the alerts. many thanks _rony
▸
On 13 May 2016 at 16:56, John Thurston <user-ce4d79d99bab@xymon.invalid> wrote:
On 5/13/2016 7:13 AM, Ron Cohen wrote:Hello there... we have here a pretty big production environments, and even bigger non-production. I've configured xymon for both, but the guys that do the actual monitoring objected to have alerts coming from non-production servers, since those are mostly non-crucial - they don't want to see any of those reds on their screens.One way that comes to mind is using the "nopropyellow" (etc) tags on the hosts. We mix our production and test hosts on pages, but mark the test hosts not to propagate their alerts upward. Their test results appear on their own page, but not on their parent page. Also look into the "nonongreen" tag. Note: the tags mentioned above affect the generation and display of the web pages. They do no affect alerts or the behavior of xymondboard. -- Do things because you should, not just because you can. John Thurston XXX-XXX-XXXX user-ce4d79d99bab@xymon.invalid Enterprise Technology Services Department of Administration State of Alaska
list Henrik Størner
Hi, Den 13-05-2016 kl. 17:13 skrev Ron Cohen:
▸
Hello there... we have here a pretty big production environments, and even bigger non-production. I've configured xymon for both, but the guys that do the actual monitoring objected to have alerts coming from non-production servers, since those are mostly non-crucial - they don't want to see any of those reds on their screens. I played for some time with the alert propagating, but it won't do, so sadly I disabled all the non-prod clients. The obvious solution (unless there's a simpler one) is to start another xymon on different port and different URL. the problem is that it requires a firewall setting, which is a major headache to make. what i thought of, is to do routing at the bb port, so incoming clients will be routed according to the IP origin to the prod and non-prod xymond (say ports 1985 & 1986). It is not difficult to implement, but before pythonizing it, i wonder if there is an existing solution within xymon which i missed, or anyone else already done it?
Xymon doesn't have a built-in solution to this - at least not that I can think of.
You could do it with firewall rules on the Xymon server, though. I suppose your non-prod servers are on another IP network (if not, the rules will be a bit messy)? With a Linux-based Xymon server you would setup some iptables redirection rules like
iptables -t nat -A PREROUTING -p tcp -s ${NONPRODNETWORK} --dport 1984 -j REDIRECT --to-ports 1985
where NONPRODNETWORK is the IP network for your non-prod servers ("192.168.10.0/24" or whatever). Xymon requests sent from the non-prod servers to port 1984 on the Xymon server will then transparently be modified to hit port 1985 on the Xymon server.
Regards,
Henrik
list Ron Cohen
Clever one :) Thanks
▸
On 16 May 2016 at 13:14, Henrik Størner <user-ce4a2c883f75@xymon.invalid> wrote:
Hi,
Den 13-05-2016 kl. 17:13 skrev Ron Cohen:
Hello there...
we have here a pretty big production environments, and even bigger
non-production.
I've configured xymon for both, but the guys that do the actual monitoring
objected to have alerts coming from non-production servers, since those are
mostly non-crucial - they don't want to see any of those reds on their
screens.
I played for some time with the alert propagating, but it won't do, so
sadly I disabled all the non-prod clients.
The obvious solution (unless there's a simpler one) is to start another
xymon on different port and different URL. the problem is that it requires
a firewall setting, which is a major headache to make.
what i thought of, is to do routing at the bb port, so incoming clients
will be routed according to the IP origin to the prod and non-prod xymond
(say ports 1985 & 1986).
It is not difficult to implement, but before pythonizing it, i wonder if
there is an existing solution within xymon which i missed, or anyone else
already done it?
Xymon doesn't have a built-in solution to this - at least not that I can
think of.
You could do it with firewall rules on the Xymon server, though. I suppose
your non-prod servers are on another IP network (if not, the rules will be
a bit messy)? With a Linux-based Xymon server you would setup some iptables
redirection rules like
iptables -t nat -A PREROUTING -p tcp -s ${NONPRODNETWORK} --dport 1984 -j REDIRECT --to-ports 1985
where NONPRODNETWORK is the IP network for your non-prod servers ("
192.168.10.0/24" or whatever). Xymon requests sent from the non-prod
servers to port 1984 on the Xymon server will then transparently be
modified to hit port 1985 on the Xymon server.
Regards,
Henrik