<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 5 December 2013 01:09,  <span dir="ltr"><<a href="mailto:henrik@hswn.dk" target="_blank">henrik@hswn.dk</a>></span> wrote:<br></div><div class="gmail_quote">

<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"><p>The way Xymon reports memory handling is very much due to historical events - how it was done in Big Brother. I agree that the "one-size-fits-all" approach in the current code is not the best way of doing it, unless your OS happens to nicely fit into the real+actual+swap metrics mold.</p>

</blockquote><div>I think many OSes do fit that mold these days.  Those that do not can probably be fudged to do a useful approximation of either real+actual+swap or actual+swap.  In most cases, the slightly nebulous "actual" number is all we care about (vs total RAM), as sysadmins who just want to know why our servers are misbehaving.<br>

</div><div><br></div><div>So while more data points would be better, perfect is the enemy of good, and currently there are no useful memory numbers for some OSes.  I don't believe it would take much to add a few more OSes into the list of those supported.</div>

<div><br></div><div>But I think there are two goals here.  One is to get "actual" memory included - that is, raise the usefulness above zero, which would be infinitely better; the other is to get all available metrics into Xymon to be available for analysis.  I think the first of these goals needs just a few minor tweaks, mostly in unix_memory_report().  The second is a much more daunting task, because of the diversity of OSes, and this is where an alternative to unix_memory_report() might be warranted.</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">
<p>You can also send data into an RRD file with a different layout, so you can have more data. Getting that rrd-graph to show up on a "memory" status is the tricky part, and right now I would recommend that you simply use a different name for the memory status.<br>

</p></blockquote><div>I think the "memory" status should show the simpler set of memory stats (including "active" if available).  If other memory stats are available, these should only be shown in trends.</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">
<p> So it is not an un-solvable problem, but someone needs to figure out just how the memory metrics can be found by the client code, and how it should be interpreted over on the Xymon server.</p></blockquote><div>Yes.  And for that reason, I think the complex option might never be completed for most, if not all OSes.  It might be better handled by custom server-side scripts that people can implement depending on their requirements.  For this to work, only the Xymon client needs to be enhanced, to report the numbers.</div>

<div> </div><div>Let me re-iterate that I'm not complaining about any part of Xymon, and fully appreciate the difficulties in collecting useful memory data from heterogeneous systems and presenting them in a uniform and consistent way.  I think the design of Xymon - even despite being somewhat an "evolved" beast - is excellent.  So what I'm trying to do is to enhance Xymon in a way that's consistent with the current architecture and future direction.</div>

<div><br></div><div>Henrik, I'm happy to do much, if not all, of the work to mod client and/or server code to support these enhancements.  However, I'd like to be confident that it fits with your future directions for memory monitoring, and avoid adding yet another data collection method hacked into Xymon, that gets used by a shrinking minority of installs.  Can you provide guidance on the best way to implement these features (or not)?  I'm proposing that I/we:</div>

<div><br></div><div>1) Enhance the Xymon client to also send "active" memory usage, for FreeBSD and any other OSes that can do this.  Also update the Xymon server to recognise the presence of "active", and make use of it in the same way that it currently does for Linux.  The client data would be in the form of an enhanced [meminfo] section of the client message.  (This could use the already-used-by-Linux [free] section, or the [memory] section used by bbwin, hpux, osf and solaris; or it could be a completely new section name, which would not be my preference).</div>

<div><br></div><div>2) Enhance the Xymon client to send the full range of OS-specific memory metrics available, included in the [meminfo] (or other) section, to apply to FreeBSD and any other OSes that can do this.  This would allow for server-side extension scripts to query the [meminfo] client data and create RRD files as required.  This would provide the _opportunity_ for Xymon to support parsing and reporting on these metrics, but this could be developed by champions of each OS who wanted the feature and knew enough to interpret what the numbers actually mean.</div>

<div><br></div><div>Cheers<br></div><div>Jeremy</div><div><br></div></div></div></div>