<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Paul</div><div class="gmail_quote"><br></div><div class="gmail_quote">Glad to see the script is working for you, mostly.</div><div class="gmail_quote"><br></div>
<div class="gmail_quote">On 14 November 2013 04:57, Root, Paul T <span dir="ltr"><<a href="mailto:Paul.Root@centurylink.com" target="_blank">Paul.Root@centurylink.com</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 lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal">Rclient happily ran the script and gave good output I can
see from debugging. It seems that xymon ignores it, I’m guessing because it doesn’t recognize ‘tripplite’ as a valid os type. Is there a way to add ‘tripplite’ as an os type? Would that be client-local.cfg?<br></p></div>
</div></blockquote><div><br></div><div>The client OS that is reported to Xymon is based on the ostype() setting in hosts.cfg. This also, by default, determines the script name to be sent to the remote system.</div><div>
<br>
</div><div>However, you can set the script name and the reported OS name to be different values like so:</div><div><br></div><div><div># 10.99.1.1 <a href="http://remserver1.example.com">remserver1.example.com</a> # "RCLIENT:cmd(ssh -T otheruser@%{H}),ostype(linux),scriptos(tripplite)"</div>
</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 lang="EN-US" link="blue" vlink="purple">
<div><p class="MsoNormal">So instead, I modified xymonclient-linux.sh and have it run. The tripplite doesn’t have uptime, so I get that from /proc/uptime and /proc/loadaverage and do a bunch of manipulations with dc.</p>
</div>
</div></blockquote><div><br></div><div>Nice.</div><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 lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"> Also, top won’t run without a terminal, and you
can’t set a terminal, so the ‘cpu’ output is a bit sparse.</p></div></div></blockquote><div><br></div><div>Must be a cut-down version of top. Is it busybox?</div><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 lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"> Ps doesn’t have any options, and says COMMAND instead of CMD, so I fix that. Also, df needed some frobbing.</p></div></div></blockquote><div><br></div>
<div>Makes you want to install Optware, and get all those GNU goodies back.</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 lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal">The last thing really, is vmstat, it doesn’t have one. So I was thinking again to using /proc/vmstat, and manipulate that, but I’m not really sure how to start there, and there isn’t a whole lot in /proc/vmstat. Any ideas there?</p>
</div></div></blockquote><div><br></div><div>No, /proc/vmstat only has info about VM. Whereas the "vmstat" command also presents info about CPU usage, memory and I/O. So the vmstat command will only provide a bit of what you need to exist in the vmstat client data.</div>
<div><br></div><div>You can get some CPU and other info from /proc/stat, but I don't think that's going to help much either. The reason is that the vmstat command provides gauge data, whereas /proc/stat and /proc/vmstat provides counter data. So you not only need to get the counters, but you also have to keep the last set of counters, calculate the differences and report those values in your pseudo-vmstat.</div>
<div><br></div><div>Running vmstat under strace shows that it hits /proc/stat, /proc/meminfo and /proc/vmstat. You can probably get all you need from those three. But again, you need to do the work to keep the last one, and do the calculations to convert counters to gauges. And you have to implement this within your (possibly incomplete) appliance's shell. Is it bash? Do you have awk/sed?</div>
<div><br></div><div>If the device supports SNMP, you might have better luck getting info from SNMP probes and constructing your vmstat client data on the server.</div><div><br></div><div>You can probably fudge some of the numbers given to Xymon. However, a quick look at the output of "rrdtool info vmstat.rrd | grep type" shows that ALL 17 numbers produced by vmstat are recorded. And a look at graphs.cfg show that most of them are included in one graph or another. Perhaps if you're only interested in (for example) graphs of memory usage stats, you can make those numbers from /proc/vmstat, and show zeroes for the rest.</div>
<div><br></div><div>Detailed descriptions about the /proc/ entries can be found here:</div><div><br></div><div><a href="http://www.linuxhowtos.org/System/procstat.htm" rel="noreferrer">http://www.linuxhowtos.org/System/procstat.htm</a><br>
</div><div><a href="http://www.linuxinsight.com/proc_vmstat.html" rel="noreferrer">http://www.linuxinsight.com/proc_vmstat.html</a><br></div><div><br></div><div>Personally, I'd consider cross-compiling (or finding) a binary for vmstat, and copying it onto the tripplite.</div>
<div><br></div><div>J<br></div><div><br></div></div></div></div>