<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 22 November 2013 08:49, Mark Felder <span dir="ltr"><<a href="mailto:feld@feld.me" target="_blank">feld@feld.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="im"><br></div>Yes, more data is better. For example, look at what Observium pulls over<br>
SNMP vs what Xymon reports:<br>
<br>
<a href="http://imgur.com/a/P4Qq1" target="_blank" rel="noreferrer">http://imgur.com/a/P4Qq1</a></blockquote><div><br></div><div>Now, that's what I want!</div><div><br></div><div>Interestingly, Observium(SNMP) splits all memory into used+cached+buffers+shared+free.  I don't know where those numbers come from - they don't map neatly to what "top" shows: active+inactive+wired+cache+buffers+free.  So used+shared = active+inactive+wired??</div>

<div><br></div><div>According to this: <a href="http://www.daemonforums.org/showthread.php?t=2125">http://www.daemonforums.org/showthread.php?t=2125</a> Net-SNMP counts cache memory twice when calculating MIB::memAvailReal.0.  It's a bit suspect.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">> So, any other suggestions on the best way to achieve this? <br>

</div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
</div>Graph it all as granularly as you can. Let the admins figure out what's<br>
important to monitor.<br></blockquote><div><br></div><div>You're correct of course.  But it's the most work, and the least likely to get completed anytime soon.</div><div><br></div><div>A bigger problem is that Xymon's genericised way of reporting memory is a call to unix_memory_report() with parameters for total, used and actual - and that's all.  (For FreeBSD and others, "actual" is set to -1.)  The function unix_memory_report() does the memory threshold checks (via status message) and also governs what gets sent to the RRD files.  If I wanted to alert on all available memory numbers, and to have them all on the graph for the "memory" page, I'd have to find another way to get them sent to the RRD files and to check for threshold violations, because Xymon is simply not geared up to do this.  And it probably won't ever be, because different OSes do memory management differently.<br>

</div><div><br></div><div>I think what I'm left with is a two-prong approach.</div><div><br></div><div>1) Improve the "memory" page: I need to have "actual" memory reported by the client, and parsed by the OS-specific code in xymond, so that it thresholds on, and generates a status message with, 3 numbers instead of two.  This needs adjustments to the client-side code client/freebsd-meminfo.c, to add an "Actual: nnn" line to its output; and also to the server-side code xymond/client/freebsd.c, to parse that line in the same way that the Linux code does.</div>

<div><br></div><div>2) Display the extra numbers: I need to get all the separate numbers - perhaps from [top] - reported into a completely separate graph (eg [topmem]), that can be viewed on the trends page.  I can knock up a server-side perl script to do that right now, but ultimately this would be best done in the Xymon server-side code (probably xymond/client/freebsd.c), and could include thresholding if it makes sense.</div>

<div><br></div><div>J<br></div><div><br></div></div></div></div>