Mike Gerdts wrote:
On Wed, Dec 9, 2009 at 9:41 PM, Rainer Heilke <rhei...@dragonhearth.com> wrote:
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.
Well, I'm not so sure about that...
Sorry, maybe I'm being a bit harsh. Then, perhaps one could say taking
corruption into account was not adequately addressed.
The key thing here is that just omitting values isn't the same as
marking them as not changed. That is, it is difficult to tell whether
the data was not measured (program error, kstat not available, system
too busy to complete monitoring) or whether it was the same as in the
last interval.
That's a fair criticism. No data is not a guarantee of anything but
there being no data.
Having data accessible as text is often useful, but it does tend to
<snip>
completed in less than a second.
Fair as well. It did take time for my graphs to generate from the text
files. I never had the option of investigating other routes. What I did
was enough of a skunk works; I couldn't spend more time on it. That
said, it became "indispensable". I could add data points, but that was it.
Or rrdtool consumes the data instantly, but the raw data is kept
around for a bit.
A fair option for paranoids like me. :-)
I was trying to suggest that in a future release of OpenSolaris, sar
would simply be a presentation layer for the data collected by this
new collection tool. If run in interactive mode, presumably that
would trigger the appropriate resolution of data to be collected for
the duration of interactive mode. 10 people running sar at the same
time in interactive mode would not cause the system to sample once for
each of them - it would cause the system to sample once (per interval)
for all of them. Assuming they picked the same interval, they would
all get the same results. This is not unlike how dtrace's tick probe
synchronizes across all users of the same tick probe.
OK, I hadn't understood that. That's a good idea, and would get around
the training issue, I think.
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.
Canada's just a little island off the coast of Mexico, right? It's
certainly somewhere where they speak Spanish with a name like that...
Off the coast of Alaska, actually. Permanently ice-bound. Named by one
of the early Spanish explorers that preceded the British.
- 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
It's things like this that make me shy away from having plain text as
the format. A web service causing frequent reparsing of a text file
would be likely to start adding a fair amount of load to the system
being monitored.
Yes, it would. Again, a fair criticism. Like I stated, I'm probably
over-paranoid due to my sar experiences. If rrdtool can store the data
cleanly and not corrupt, then maybe it should do the job.
I should take a look at Amber Road. Third-party software like this was never
an option at my old job.
And right now it is only on OpenStorage. Quite a shame, really.
So, I probably won't be able to look at it at all. :-(
Rainer
--
Mind the Gap
http://www.dragonhearth.com/blogs/rheilke
_______________________________________________
sysadmin-discuss mailing list
sysadmin-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss
