[Xymon] Using rclient to connect to a Tripplite terminal server

[Root, Paul T]

From: Jeremy Laidman [mailto:jlaidman at rebel-it.com.au]
Sent: Wednesday, November 13, 2013 7:48 PM
To: Root, Paul T
Cc: xymon at xymon.com
Subject: Re: [Xymon] Using rclient to connect to a Tripplite terminal server

Paul

Glad to see the script is working for you, mostly.

On 14 November 2013 04:57, Root, Paul T <Paul.Root at centurylink.com<mailto:Paul.Root at centurylink.com>> wrote:
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?

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.

However, you can set the script name and the reported OS name to be different values like so:

#        10.99.1.1 remserver1.example.com<http://remserver1.example.com> # "RCLIENT:cmd(ssh -T otheruser@%{H}),ostype(linux),scriptos(tripplite)"

Very nice. I'll do that, thanks.
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.

Nice.

Also, top won't run without a terminal, and you can't set a terminal, so the 'cpu' output is a bit sparse.

Must be a cut-down version of top.  Is it busybox?

It is busybox.
 Ps doesn't have any options, and says COMMAND instead of CMD, so I fix that. Also, df needed some frobbing.

Makes you want to install Optware, and get all those GNU goodies back.

No kidding.
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?

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.

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.

Yeah, it seemed like a lot of work for little value for a terminal server.


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?

If the device supports SNMP, you might have better luck getting info from SNMP probes and constructing your vmstat client data on the server.

It does have SNMP, maybe I'll look at that.


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.

Detailed descriptions about the /proc/ entries can be found here:

http://www.linuxhowtos.org/System/procstat.htm
http://www.linuxinsight.com/proc_vmstat.html

Personally, I'd consider cross-compiling (or finding) a binary for vmstat, and copying it onto the tripplite.

J

Thanks,
Paul.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20131114/7958d030/attachment.html>