[Xymon] devmon/xymon wishlist or feature requests

Novosielski, Ryan novosirj at umdnj.edu
Fri Jun 7 20:21:27 CEST 2013

I really like Xymon suggestion #3.

Incidentally, the day after Thanksgiving code is still fouled up last I looked (4.3.10).

From: taylor lewick [mailto:tlewick at apsaranetworks.com]
Sent: Friday, June 07, 2013 02:05 PM
To: xymon at xymon.com <xymon at xymon.com>; devmon-support at lists.sourceforge.net <devmon-support at lists.sourceforge.net>
Subject: [Xymon] devmon/xymon wishlist or feature requests

Cross posting to both the devmon and xymon mail lists.

The following features for devmon, would in my opinion, greatly extend/enhance the snmp monitoring capabilities of devmon/xymon.

1.       Devmon should be able to poll different devices on different intervals.  Having a global poll cycle is too limiting.

For example, there may be a piece of critical SNMP data that you need to query on a device, but its limited to only one or two MIB objects.  For SLA or other reporting purposes, you may need to poll every 10 seconds or 5 seconds.  But for most other devices, or devices with large MIBs (Network switch) every 5 minutes might be sufficient.  Such a setup would allow you to aggressively poll the devices you need to, while not causing SNMP responses to exceed the poll time on the other devices.  We run into this issue now while trying to poll key devices, if we tighten the polling cycle, we start to get timeouts on our “larger” devices, as the latency over the VPN connection is a bit high.  If this is something devmon supports, I am not aware of it, and I’ve used both single node and multimode (database based) versions.

2.       Devmon should easily support logging any/all retrieved SNMP data to a database.  I setup the multinode installation and saw the test_data table in mysql, and was excited as I thought the data would be logged there.  Turns out no, and then after some researching looks like a method was started to be able to use it, i.e. dbtable.  I downloaded the code from sourceforge, but was unable to get it to work.  I think better integration or documentation of this feature would be very nice.  Here the justification should be obvious, sometimes the RRD graphs aren’t sufficient for the granularity they provide, and having access to your SNMP data in a sql database can be very valuable/insightful.  Again, if anyone knows how to do this, I’d love to find out more about how to implement it.

Xymon Feature/bugfix requests: (I’m running 4.3.8, so if the following features are available in a later version, great).

1.       After a reboot of the xymon server, any of the disabled devices, always come back enabled.  These should persist past a reboot.  A reboot shouldn’t invalidate the fact that I’ve knowingly disabled a device, or if it does, there should be an option to allow you to select disabled devices persist after reboot and/or restart.

2.       Also, I’ve noticed  a bug with xymon dates, currently if I disable an alert and I select say 6 months out, it marks the times as something nonsensical.  For instance, I currently disabled a few hosts and chose disable until November 1, 2013, and they are saying disabled until Sat Jun 14, 14:13:44 1902.  At some random time, usually a few days to a few weeks later, they re-enable themselves, which is annoying.  I just read the 4.3.9 through 4.3.11 release notes, and the 4.3.9 release notes state “Fix error in disable-until-TIME or disable-until-OK code”  Does this fix address the same bug I just described?

3.       Would like to request a disable/reenable all alerts via one button on the enable/disable screen.  It should be smart enough so that if you already have some hosts disabled, then upon re-enabling the alerts those hosts still have their disable settings applied.  We have some devices we monitor which degrade in poor weather, and when a big storm comes through it would be nice to just click one button and halt alerting.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20130607/1cbef639/attachment.html>

More information about the Xymon mailing list