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!