On Fri, February 6, 2015 5:20 pm, LOZOVSKY, DANIEL L wrote:
Thank you everyone for your help. Actually, I did not anticipate this quick response. This xymon community is great. I keep learning new things just by reading everyone's email. It is great to be part of this community. I have been pushing AT&T to utilize xymon instead of nagios. I have been using BB open source version for almost 10 years and it really saved us at Supply Chain. Of course, I had to make a lot of modifications to it. Xymon is the next logical step to help make things much better.
That's wonderful to hear! We aim to please :)
At ServiceNow, we performed a migration from Icinga over to Xymon as our primary internal monitoring system framework, so the Nagios->Xymon switch is definitely doable.
One of the things I think you'll find most helpful is the ease by which Xymon messages can be crafted. Since conceptually, everything in xymon is a "passive test" (from xymond's perspective, xymonnet is simply another test-result submitter), this makes it very easy to take tests fired off locally (or via NRPE) and wrap them in small xymon shell wrapper bits (see https://www.xymon.com/help/xymon-tips.html#scripts) to get them working quickly.
Later on, you can go back and enrich the data sources beyond the typical everything-on-one-line format to provide a more "Xymon-y" feel, but that can ultimately be handled at your leisure...
Our primary hardware monitors are still essentially this; a Xymon enrichment script wrapped around the check_openmanage Nagios check (http://folk.uio.no/trondham/software/check_openmanage.html) running via 'xymonlaunch' on each host -- simply because there wasn't a need to replace the evaluation logic we'd already been using.
Welcome to the list!
-jc