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