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.
intervals. Having a global poll cycle is too limiting.Devmon should be able to poll different devices on different
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.
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.Devmon should easily support logging any/all retrieved SNMP data to
Xymon Feature/bugfix requests: (I'm running 4.3.8, so if the following features are available in a later version, great).
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.
Also, I've noticed a bug with xymon dates, currently if I disablean 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?
Would like to request a disable/reenable all alerts via one buttonon 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.
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.
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.
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).
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.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?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.
You Devmon ideas are pretty good. I don't think there is any development going on on it however. It has been stuck at 0.3 whatever for a very long time, on SourceForge. I would change to something else, but haven't found anything.
As to your second question on Xymon.
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?
We ran into this, but our setup was a bit unique. We have two proxy servers that also operate as backup servers. So they have the proxy function that sends to the primary server, but they also have a server function on port 1985 that the proxy also forwards too. That way if the primary goes down , they can take over.
So there is a mismatch on how dates are handled in there somewhere. And we added to our disabling on the primary to inform the secondary's, i.e. sending the message on. Well, with the difference in handling the raw date data, we got into a cyclical issue of the primary telling the proxy, and the proxy sending it back. If you watched it, the disable time changed multiple times until it cleared itself.
We upgraded to 4.3.10, but it still happened. Then I figured out, we don't want to tell the proxy, we want to tell the server. So we adjusted the primary to send the disable message to 1985 instead of 1984 and all was well.
So, in short, 4.3.10 does help in this issue, and may fix what issues you have, but you may need some other work.
A disable works over reboots for me. Maybe that's a 4.3.8 issue. I'm on 4.3.10.
I was thinking that disables were just kept in memory not disk. Maybe that change between .8 and .10?
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of taylor lewick Sent: Friday, June 07, 2013 1:05 PM To: xymon at xymon.com; devmon-support at lists.sourceforge.net Subject: [Xymon] devmon/xymon wishlist or feature requests
Xymon Feature/bugfix requests: (I'm running 4.3.8, so if the following features are available in a later version, great).
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.
On Fri, 7 Jun 2013, taylor lewick wrote:
After a reboot of the xymon server, any of the disabled devices,
This is not a bug in xymon. Your system is configured incorrectly.
Sounds like you are using the rpms from http://terabithia.org/rpms/xymon/ There is a packaging bug in those rpms. See http://lists.xymon.com/pipermail/xymon/2013-March/037082.html for info on the cause and how to fix it.
Even if you are not using the rpms, the fix still applies.
Hope this helps.
Regards,
-- Tom me at tdiehl.org Spamtrap address me123 at tdiehl.org
participants (4)
-
me＠tdiehl.org
-
novosirj＠umdnj.edu
-
Paul.Root＠centurylink.com
-
tlewick＠apsaranetworks.com