A wee bit of lag on this response.<br><br><div class="gmail_quote">On Oct 15, 2007 6:38 AM, Henrik Stoerner <<a href="mailto:henrik@hswn.dk">henrik@hswn.dk</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d"><br></div>I haven't had a lot of requests for more granular data to begin with;<br>most of the requests have been for the fine-grained (5-minute) data to<br>be maintained for a longer period of time than the current 48 hours.<br>
In the next version (or the current snapshot), you can define RRA's<br>individually for each type of RRD files. So you can configure the vmstat<br>RRD's to maintain the fine-grained data for a longer time. That should<br>
take care of this issue.</blockquote><div><br class="webkit-block-placeholder"></div><div>Adding the ability to define RRA's for each RRD is a very nice feature.  I definitely believe the the stock RRA's should be adjusted to meet user requests. As I've mentioned before, the original RRA definitions were very arbitrary.</div>
<div><br class="webkit-block-placeholder"></div><div>Thinking out loud:  I believe we could redefine the stock RRAs for each RRD that could handle the need to keep data longer, and the ability to keep more granular forms of data.  This *should* be a simple change that is completely backwards compatible and would not mandate a more granular sample rate.   But, by doing so, Hobbit could from this point forward, would allow for both, without RRA/RRD manipulations.  "Migrating old RRDs" would then be an independent task.</div>
<div><br class="webkit-block-placeholder"></div><div>For example, create a new RRA structure which allows for (rough draft):</div><div><br class="webkit-block-placeholder"></div><div>5 second samples for 48 hours (the granular RRA we don't have today)</div>
<div>1 hour samples for 400 days (this gives the ability to run business "reports" over at least the last year)</div><div>24 hour samples for 9600 days (24*400=9600 I think I understand what the Y2K bug creators went through, I can't imagine this code running 9600 days from now!  But then how many times I've missed data flowing off the 576 day chart!)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d"><br></div>If I understand your suggestion correctly, you would change the client<br>to run "vmstat 5 61" (for instance), collect all 60 samples, and then<br>
send them off to Hobbit every 5 minutes. So we would essentially be<br>caching data for 5 minutes on the client, then send it off to the Hobbit<br>server and do a single multi-update of the RRD data when it arrives.</blockquote>
<div><br class="webkit-block-placeholder"></div><div>Exactly.  I don't know if rrdtool has the ability to handle "batch" inputs, but it would be nice for this.  Since file IO is such an issue anyway, I'd hate to aggravate the condition.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">way off. I guess this could be done by having the client timestamp the<br>data, but then use these as relative timestamps (so we can see sample 10<br>
was done 236 seconds before the last sample) and then work out the exact<br>timestamps over on the Hobbit server, like we do today.<br></blockquote><div><br class="webkit-block-placeholder"></div><div>I'd say keep the time "interpretation" exactly the same as before since it has worked.  The increase of samples are merely offsets from the current single input.  I don't see any reason to change the logic.</div>
<div><br class="webkit-block-placeholder"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>This could be done - it would require a bit of change to the clients,<br>
but I'm not really happy with the current way the vmstat data collection<br>works (it usually leaves a vmstat process hanging around when the client<br>is stopped), so I wouldn't mind having to do some code for this. I'd<br>
probably write a small tool to run "vmstat 60" so it runs forever, and<br>then the tool would pick up the data, timestamp it and then regularly<br>feed it into the client report.</blockquote><div><br class="webkit-block-placeholder">
</div><div>Heh, it's annoying how such an ugly shell hack can work so well.  I think going to a "vmstat 60" running all the time would only move where the ugliness happens (from the collector, to the parser--plus you'd still have to keep track of the PID, and kill it on hobbit shutdowns).  The only "clean" way I can think of is to make the collectors run once per sample:  e.g. "vmstat 5 2".  We are also bumping into statistical problems because vmstat info is a "rate" (something/second) and other data is a gauge (something).  I think it's a scalar vs. vector issue. RRD can of course deal with input streams of GAUGE or COUNTER (DERIVE was used as a "poor-mans" solution to kill spikes), but not all metrics are available via COUNTERS (e.g. load average).  But you can get COUNTER for system calls).</div>
<div><br class="webkit-block-placeholder"></div><div>The currently collection of the metrics might be ugly but it works.  I'd be really amazed if cleaner way could be developed.  The *stat commands give a nice abstraction layer to kernel metrics, that I think overall would be a nightmare to normalize across platforms.</div>
<div><br class="webkit-block-placeholder"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>And of course the server-end would need changing to accomodate the new<br>
data format and the multiple updates.  It's certainly doable, without a<br>whole lot of re-designing.<br><br>But I think we should consider which datasets one might want to have<br>these frequent updates for. vmstat is obvious; but what about memory<br>
utilisation? Disk utilisation rarely changes rapidly - or perhaps it<br>does ? Process counts? Network test response times ? Once we start doing<br>it for vmstat, I'd expect everyone to come forward and ask for it for<br>
lots of other datasets - so instead of doing a quick hack just for<br>vmstat, we should consider what would be the "right" way of doing it for<br>all/most of the data.</blockquote><div><br class="webkit-block-placeholder">
</div><div>This is a symptom of one of the bigger issues I ran into with larrd development:  the chicken and egg dilemma regarding collecting, parsing, and reporting metrics.  You need to define all three, but you don't necessarily know how you'd like to see data until you see it, which of course affects how you collect it.</div>
<div><br class="webkit-block-placeholder"></div><div>Over the years, I've been drawn towards the "industrial strength" "one size fits all" architectures vs. "super custom elite" configurations. Curtis Preston in his backup book, has a saying, "special is bad."  I agree whole heartedly.</div>
<div><br class="webkit-block-placeholder"></div><div>This means despite the fact I can't think of one good reason why disk usage should be kept at five second intervals, customizing each RRD for the data would be a pain.  If the heartbeats were general enough, we could define a "stock RRA structure" that could handle data inputted at 5 or 300 second intervals.</div>
<div><br class="webkit-block-placeholder"></div><div>Since you've already got the code to handle custom RRA configurations for each RRD this may be a moot point.</div><div><br class="webkit-block-placeholder"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">> $ vmstat 1 301 would definitely be a bad idea.<br><br></div>Agreed - but I don't think that should be something Hobbit decides. I<br>can easily imagine a scenario where you would do that for some<br>
troubleshooting situation, and if that is what is needed then Hobbit<br>should let you do it. No reason to setup arbitrary restrictions.<br>(This is in line with Unix thinking - "if you insist on shooting your<br>foot off, it's your decision to do so". Just as "rm -rf /" is not<br>
recommended, but still possible).</blockquote><div><br class="webkit-block-placeholder"></div><div>As long as the stock configuration is not brain dead, I won't loose sleep over giving administrators enough rope to hang themselves.  Although generally speaking, I prefer systems that protect users against themselves.</div>
<div><br class="webkit-block-placeholder"></div><div>So the long and short of all of this, is the request that with the 4.3.0 release the standard RRAs within RRDs being created could handle the requirement of 5 second samples, 1 hour samples kept for at least one year, and "keep one day samples longer than you think you could possibly need them."</div>
<div><br></div><div>-Scott</div></div>