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