[Xymon] web configuration of xymon
John Thurston
john.thurston at alaska.gov
Wed Apr 1 18:52:37 CEST 2015
On 3/27/2015 8:02 AM, Tracy Di Marco White wrote:
> Hi all,
>
> We've been adding a lot of servers and services to our xymon monitoring
> deployment, and it's become somewhat more complex to manage changes to
> monitored hosts/services, as well as what's critical when, and what
> alerts are needed when. I'd like to deploy a web interface, with access
> controls of course, where people can change what systems are monitored,
> and what services on those systems are monitored, as well as what alerts
> they get when. Because there is so much flexibility in xymon, this can
> get fairly complex, and I want to add an error checking web interface to
> people's ability to change these settings.
>
> Does anyone already have something like this?
I think you may be looking for "MAGMA" which was a work in progress by
Squidworks back in 2012.
http://lists.xymon.com/pipermail/xymon/2012-October/035876.html
> MAGMA is an add-on web GUI for managing Host, Groups and Alarms on a XYmon 4.3 or newer system.
> How does it work?
> ---------------------------
> It stores all alarm and host/group configs in the SQL database and rewrites the Host.cfg, Analysis.cfg and
> Alarms.cfg files causing the XYmon system to update its tests and pages based on the changes in these
> files. It will overwrite the files each time a host is added or edited making the process of updating
> automatic. To get the full benefit of MAGMA you should place all hosts in "central" mode, although this is
> not required, without it your management is somewhat restrictive (external test management only). In
> Central mode you get full management features for all tests.
The site was live a couple of months ago, but I don't get anything from
it now. I don't know if that is because the site is down, or because my
workplace is blocking it. You could check the Wayback Machine at
www.archive.org, but I can't because my workplace blocks that. You could
also check the cached content in google, but I can't because my
workplace also blocks that.
I looked briefly at MAGMA but pulled the plug on it in short order. It
seemed silly to me to take an application with a lot of config files of
varying complexity, and front it with another application (with its own
authentication and authorization) reliant on PHP and mySQL. It was
increasing the complexity and difficulty of support and recovery, while
not really meeting a business need of ours.
In our installation, we have 1,223 hosts which are subject to only
'ping' tests. These hosts are managed by scripts fed from our DNS, and
require no day-to-day intervention from humans. (The last time a human
touched those files was in April, 2013.)
We have about 650 hosts defined with clients. The hosts.cfg is handled
day-to-day by by four admins by means of a script which implements
simple file-semaphore locking and date-stamp versions. It is simple, and
meets our current needs. If we outgrow this, we will probably go to
nested .cfg files with 'include' statements. Doing that would let us
limit the potential damage from a bad edit without having to deploy more
complex admin tools.
The management of alerts.cfg is really handled by a single person. The
rules and options available have turned out to be too complex to
delegate. An application or system owner will come to me and I'll help
nail down what their business needs are and determine if they are
providing Xymon enough information that an alert can be written to meet
that need.
Our clients are all handled in "local mode". We do not support "central
mode". It is the responsibility of the client-node admins to configure
their client software to meet their business needs. The Xymon admins to
not have privileges to configure or run code on most of the hosts
reporting to Xymon.
--
Do things because you should, not just because you can.
John Thurston 907-465-8591
John.Thurston at alaska.gov
Enterprise Technology Services
Department of Administration
State of Alaska
More information about the Xymon
mailing list