<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"><meta name="Generator" content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
h3
{mso-style-priority:9;
mso-style-link:"Heading 3 Char";
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:13.5pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.Heading3Char
{mso-style-name:"Heading 3 Char";
mso-style-priority:9;
mso-style-link:"Heading 3";
font-family:"Times New Roman","serif";
font-weight:bold;}
span.EmailStyle19
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1100830721;
mso-list-type:hybrid;
mso-list-template-ids:-956385634 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:1176722721;
mso-list-type:hybrid;
mso-list-template-ids:-606337644 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang="EN-US" link="blue" vlink="purple"><font style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">
I really like Xymon suggestion #3. <br><br>Incidentally, the day after Thanksgiving code is still fouled up last I looked (4.3.10). <br><br></font><br> <br>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<font style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<b>From</b>: taylor lewick [mailto:tlewick@apsaranetworks.com]
<br><b>Sent</b>: Friday, June 07, 2013 02:05 PM<br><b>To</b>: xymon@xymon.com <xymon@xymon.com>; devmon-support@lists.sourceforge.net <devmon-support@lists.sourceforge.net>
<br><b>Subject</b>: [Xymon] devmon/xymon wishlist or feature requests
<br></font> <br></div>
<div class="WordSection1"><p class="MsoNormal">Cross posting to both the devmon and xymon mail lists.<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal"><b>The following features for devmon, would in my opinion, greatly extend/enhance the snmp monitoring capabilities of devmon/xymon.<o:p></o:p></b></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman""> </span></span><![endif]>Devmon should be able to poll different devices on different intervals. Having a global poll cycle is too limiting. <o:p></o:p></p><p class="MsoListParagraph">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.<o:p></o:p></p><p class="MsoListParagraph"><o:p> </o:p></p><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman""> </span></span><![endif]>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.<o:p></o:p></p><p class="MsoNormal" style="margin-left:.25in"><o:p> </o:p></p><p class="MsoNormal"><b>Xymon Feature/bugfix requests: (I’m running 4.3.8, so if the following features are available in a later version, great).<o:p></o:p></b></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo4"><![if !supportLists]><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman""> </span></span><![endif]>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.<o:p></o:p></p><p class="MsoListParagraph"><o:p> </o:p></p><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo4"><![if !supportLists]><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman""> </span></span><![endif]>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 “<span style="font-family:"Courier New";color:#555555;background:white">Fix error in disable-until-TIME or disable-until-OK code” </span><span style="background:white">Does this fix address the same bug I just described?</span><o:p></o:p></p><p class="MsoListParagraph"><o:p> </o:p></p><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo4"><![if !supportLists]><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman""> </span></span><![endif]>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.<o:p></o:p></p><p class="MsoListParagraph"><o:p> </o:p></p></div></body></html>