I want to agree with elements of both Isaac & Paul's statements.
In my environment, you cannot use anything but a command line to enter the environment. (high security, no GUI, only SSH port on nonstandard port). If I can no longer enter my environment and SSH to my Xymon host, I can no longer use it. We actually don't even use the generated web pages at all. I scrape files & push data around in the back end over listeners I've written and into disparate systems with dissimilar interfaces.
Now what?
If a database is in the offering, a way to both manage and dump that database would be of paramount importance, or we would have to write our own system. Sure, we've already pretty much done that (all in perl) to wrap all the cool stuff Xymon does with its clients and the daemon, and have highly customized it to an extremely secure environment, so we are the minority and I understand that.
Just note that it does have an effect on the install base to remove funcitonality (i.e., adding in favor of a new way). This definitely kills things under various circumstances, and can eliminate users rather rapidly.
What of the support files and documents, etc.? I have a customized Linux installation that runs just shy of 400M. The post-provisioning varies from 150-300M on top of that for a very small, very tight installation. Adding more packages to support a "new and improved" Xymon might be more of an undertaking. I'd have to re-roll my provisioning image, write puppet manifests/classes/facts to support the new packages. I'd have to do a deployment of all the new packages across over 10,000 hosts, and then deploy, without downtime, without operational interference.
I guess that what I'm trying to say is that large heterogenous environments would be seriously impacted.
Thank you SO much Henrik for the amazing tool you've produced. It's an outstanding effort, and I, for one, am eternally grateful at all the hard work and years you've put into it.
Jerald Sheets
Apple, Inc.
On Jun 14, 2012, at 11:55 AM, Isaac W Traxler wrote:
Some folks have taken this thread to be a general what-if you could do this, so I have joined that group. I suspect some of the things I want already exist and Ihave not dicovered them yet or am to obtuse to figure out.
Comments about flat files vs GUI:
- Flat files certainly offer a lot of options
- A syntax checker would be nice
- A GUI might attract some folks, but it is more likely to remove
flexibility for the rest of us
- Like others, I have been looking at generating the hosts.cfg file from
data in racktables and additional custom tables
- Most of the current Xymon users chose Xymon because of its simplicity,
light weight, flexible configuration and its extensibility -- would a
change create a fork?
Database comments:
- What impact will it make on resources (xymon is frugral)
- What about databse crashes/recovery
- Will it improve performance
- Does it replace text files
- How many additional packages must be installed
Side note: I started monitoring with Big Brother many years ago. I made efforts with Nagios and Zabbix. I cam back to Xymon. Xymon is not perfect.
But it is light weight (Zabbix out ran my resources with a couple of dozen machines monitorred). It lives in a push or pull model (I am often amazed at how differently people implement Xymon). Xymon will do just about anything (I just need to be bright enough to write a script).
Features that I would like:
- better snmp support (some devices are basically only snmp)
- recent non-green page (only events that have happened in last
configurable time period)
- disk graphs -- a way to indicate disk size changed (kind of like the
arrows on a stock graph to indicate a split)
- column view -- the ability to pick 1 (maybe more columns) and see all
machines for only that column
- A good way to handle events. Events happen and can easily generate a
Xymon message. A good, consistent method for those events to go away,
reset to green, or something would be nice. In particular, I (and
others) have spent lots of time processing syslog messages. I could
generate dozens of messages from syslog events. Unfortunately, most
do not have a follow event to indicate the first event is over.
- Web content that was happy with iPhone/iPad
- Alternate web front end/dashboard. When trying to convince others
of the value of Xymon I get beat up over the "dated" web look
more than I the lack of GUI config or lack of database technology
(in fairness I often hear folks complain about the lack of a database
until the see how fast, efficient and low memory the Xymon design is).
Areas that I know can be done but I have not found the doc for yet:
- Rules to not page on events x,y,z if A is down
- Aggregation -- I would like to create a test that is the OR of
several tests and display it as another column. Clicking on that column
takes you to a page of the individual tests. Example: I have a number
of DataDirect Network Controllers that I can poll and determine quite a
few different errors. At first I tried a single DDN test and discovered
I often missed a later important event becasue an earlier minor one had
happened and I was ignoring the test. I have now separated the
individual tests out (I currently have 9). A way to "macro" these
together would be neat.
--
Isaac Traxler AIX,Linux Admin
Louisiana State University user-4dfb0dbf036e@xymon.invalid
High Performance Computing XXX-XXX-XXXX
LONI AIX Clusters
AIX, Linux Support
Storage and Infrastructure