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
