Resubmitted after subscribing to Observability-discuss to keep threads
complete. RHH
Mike Gerdts wrote:
>>
>>> - Only save the processed data that sar uses. Compatible, but useless.
>> Actually, that's better than sar. But now I'm just repeating myself. :-)
>
> And to support my previous claims that sar is useless because it has a
> propensity to corrupt data:
"Propensity"? That's a little mild, isn't it? I would tend to lean
toward the hypothesis that it is _designed_, however unintentionally, to
corrupt its data.
>>> - Compress in the time domain, so you don't keep saving the kstats
>>> that don't change. (A quick test on my desktop - only 10% or so of
>>> the statistics actually change over an hour.)
>> I like this--only keep the data that changes. You need to be careful
about
>> how you parse (sed/grep/awk/Perl) it, though.
>
> If any sort of compression is used (such as not repeating values that
> are observed to be the same as the last time) it is essential that
> there is a robust decompression mechanism (API and command). The
> output of such a command can be piped to traditional tools.
I don't think of this as compression, just as not storing data that
hasn't changed. The data, IMO, must remain as text. While an API would
be very useful, I'm strongly opposed to converting the data into a
format that sed/awk/grep/Perl cannot consume directly. The API would
merely be a front-end to simplify the filling in of blank fields in my
perspective of what is stored.
>> We really need to make sure Sun (I'm thinking of the support wings)
to buy
>> into anything we do, though. As long as they insist on sar data, we're
>> hooped.
>
> Sampling at a higher rate with automatic roll-up and pruning is very
> helpful. This is the key to the success of rrdtool. This is also the
> approach used by the analytics found Sun's commercial webstack
> offerings. After seeing rrdtool behind the scenes in webstack, it
> makes me wonder if it is also used in the analytics with Amber Road.
Agreed, but I would prefer rrdtool consumes the data one or two days
later. On any given day, I want to be sure I can easily access that
day's and the day before's data. Perhaps I'm being overly paranoid due
to my sar experience, and my argument is meaningless. rrdtool shouldn't
trash the data like sar.
I think you understand my paranoia, though, based upon your sar stats above.
> The interface to sar is a handful of commands. It should not be hard
> to provide the same commands that get their data from whatever format
> is chosen as a successor. When support asks for sar data, you can
> give it to them.
Having dealt with Sun many times, I am all too conscious of this not
being good enough for some engineers. They'll want the sar data, not
data that's the same as sar's. Yes, very stupid, but all too probable
from my experience. The time intervals have nothing to do with this.
Don't get me wrong; I've dealt with some amazing engineers. But I've
also dealt with a few that seemed to have been hired right after they
got their MCSE. :-(
And then there was the one from Texas who couldn't understand how I
could both live in the Mountain time zone and in Canada at the same time.
> And on the wishlist
>
> - A web service or similar that makes it possible to collect this data
> or do analysis that spans systems.
> - API's and tools that can talk to these web services and aid in data
> visualization.
Excellent! +1
> FWIW, I have repeatedly asked Sun to sell me Amber Road style
> analytics for use on Solaris boxes. I can't say that I have heard any
> indication that they will ever deliver such a thing. Perhaps this
> effort can be a step in that direction.
I should take a look at Amber Road. Third-party software like this was
never an option at my old job.
Rainer
--
Mind the Gap
http://www.dragonhearth.com/blogs/rheilke
_______________________________________________
sysadmin-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss
