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

[Jeremy Laidman]

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> 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 # "RCLIENT:cmd(ssh -T otheruser@
%{H}),ostype(linux),scriptos(tripplite)"

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?


>   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.

 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.

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20131114/ec2290c2/attachment.html>