[Xymon] Xymon script for linux
Bruce Ferrell
bferrell at baywinds.org
Mon Sep 23 23:23:28 CEST 2019
On 9/23/19 11:14 AM, Japheth Cleaver wrote:
> On 9/23/2019 4:46 AM, Bruce Ferrell wrote:
CLIPPAGE HERE
> That's basically how the version I had spec'd out operated. It would be a set of parallel sadc processes writing out to temp files, get turned into textual output by 'sar', and
> then payloaded up in the client message:
>
> > $SADC -F ${SADCOPTS} -L ${SADCFREQ} $XYMONTMP/xymon_sadc.$MACHINEDOTS.$$; $SAR -A -f $XYMONTMP/xymon_sadc.$MACHINEDOTS.$$ > $XYMONTMP/xymon_sar.$MACHINEDOTS.$$; mv
> $XYMONTMP/xymon_sar.$MACHINEDOTS.$$ $XYMONTMP/xymon_sar.$MACHINEDOTS; rm -f $XYMONTMP/xymon_sadc.$MACHINEDOTS.$$
>
> Another option would be to transmit just the sadc binary datafile, but it seemed likely that could vary in structure among differing releases, while sar-processing scripts and
> tools that can interpret the text feed are pretty numerous.
>
> As a side benefit, having per-minute sar output for the 5 minutes prior to an event occurring in the client message could be useful for postmortems.
>
> The downside, of course, is that the text output is indeed huge. Even if it's transmitted compressed, it's still greatly bumping up your resource utilization. That suggests that
> the benefits of having full text output in the client message might be outweighed by the space savings in just having clients send direct "sar" data messages back themselves.
>
>
>>
>> vm/io/whatever stat collects a sample and sends just that sample. All storage is at the xymon server MUCH cleaner even if adding the rare/exotic new thing is harder when they
>> come up. BTW, sar on OS X is a way different beast too, so it violates the premise that the same code works. but *stat works out of the box.
>
> Of course OS X has to be different :)
>
> -jc
>
>
Well, BSD in general, but considering BSD *IX is kind of where it all started, which one is the deviant? And shall we discuss SNMP! Oy vey!
More information about the Xymon
mailing list