Mike Gerdts wrote: > On Wed, Dec 9, 2009 at 9:41 PM, Rainer Heilke <rheilke at 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
