[Xymon] Hand editing config files

[Jerald Sheets]

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                traxler at lsu.edu
> High Performance Computing                225-578-1923
> LONI AIX Clusters
> AIX, Linux Support
> Storage and Infrastructure
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20120614/98d3d926/attachment.html>