<br><br>
<div><span class="gmail_quote">On 12/13/05, <b class="gmail_sendername">Scott Walters</b> <<a href="mailto:scott@packetpushers.com">scott@packetpushers.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>> In all my years of Systems Administration, things that run every<br>> minute all the time usually end up being a "Bad Idea".
<br><br>> How will a smaller sampling period improve the service you provide?</blockquote>
<div> </div>
<div>It can be a bad idea sometimes, others not (for example, the reply from</div>
<div>the person catching intermittant problems with BB running every minute)</div>
<div> </div>
<div>A smaller sampling period can show things in a more granular aspect. For example, a process kicks off and 5 minutes later you see 100 errors (im keeping things generic for illustrative purposes) Were those 100 errors in the first minute? the last? constantly throughout the 5 minutes? 
</div>
<div> </div>
<div>Im not saying your wrong, simply pointing out that it's not as black and white as your making it.</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> My job requires data be useful, not just interesting.  That is not to<br>> say there aren't jobs were useful is good enough.
</blockquote>
<div> </div>
<div>Something being just interesting initially can sometimes uncover problems that</div>
<div>you didn't see before.</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">>> The graph DB's that vmstat feeds data into (the RRD files) are<br>>> constructed in such a way that a 5-minute interval is what makes
<br>>> sense. So running them with anything else really just a waste of<br>>> ressources.<br><br>> With the stock larrd/hobbit RRD definitions you are correct.  He'll<br>> only use one of the five, and whine about the timestamp of the other
<br>> four.</blockquote>
<div> </div>
<div>Firstly, can you explain your comment in more detail? Secondly, </div>
<div>im confused as to why you would state that I would "whine" about anything</div>
<div>when you have no basis for a conclusion to that effect. It seems to be a rather</div>
<div>pointed comment in a discussion that hasn't involved the use of language that</div>
<div>would dictate a response like that.</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">>. The design goal of larrd, (I can't speak for Henrik and hobbit/RRD)<br>> was capacity planning and trending.  5m samples are  more than
<br>> adequate for that activity.<br><br>> IMO, sampling at a high frequency implies real-time performance<br>> analysis, and I've always felt that outside the scope of capacity<br>> planning and trending.  EG. We don't run sendmail in debug all the
<br>> time . . . .<br><br>> All that being said, those long term trends are very helpful for<br>> problem resolution.  One can compare a single 5m sample against an<br>> aggregate of 5m samples and determine if things are 'normal'.  But
<br>> the art of comparing all the activity within a single 5m sample for<br>> normal is very very difficult.</blockquote>
<div> </div>
<div>That is a very good point you make. There is a difference between </div>
<div>real-time analysis and capacity planning/trending. I don't however think </div>
<div>that it is that far outside of hobbit's scope to try and leverage it for </div>
<div>a more pointed analysis. My goal isn't to take every machine in my environment</div>
<div>and make them into 1 minute sampling period machines. To have the ability to do</div>
<div>so on a machine-by-machine basis could be useful</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>> That's my design you inherited and because of the complexity of the<br>> parts, I think it is a very solid design.  
</blockquote>
<div> </div>
<div>I don't think anyone is really questioning that.</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> To become flexible enough<br>> to handle different sampling rates, the server would need to know the
<br>> frequency of the tests.  And then changing the RRD in the future is<br>> 'almost' impossible (very difficult at the least).  And I've never<br>> seen what happens to 1.5 years of data when you start messing with
<br>> the RRD.<br><br>> In the end, I think you'd get the worst of both worlds.</blockquote>
<div> </div>
<div>Honestly, I don't claim to know anything about the way larrd and hobbit</div>
<div>are coded in the slightest. There are difficulties to be sure, but part of having a </div>
<div>community such as this is to foster ideas and innovation. Just because you</div>
<div>don't think it's useful or that it's hard doesn't mean the same is true for everyone out</div>
<div>there. What if you could add a high-frequency tag to a server and it generates a seperate</div>
<div>high-frequncey graph for that, as well as updating the normal trend graph for whatever</div>
<div>resource you wanted? That way you could choose for a day to look at a graph for resource x every minute for a day then turn it off? There are lots of ideas and I don't know if mine would even work, but you shouldn't just kill the idea.
</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> I disagree.  If real-time performance analysis is needed, I would<br>> pick other tools --  "vmstat 5"  works for me;)  Or construct/fork
<br>> the client agent specifically designed for such a task, and run it on<br>> an as-needed basis.</blockquote>
<div> </div>
<div>There are other tools yes. I am trying to leverage hobbit. If it's not possible</div>
<div>and nobody wants to do it, then yes, ill look into other tools. On the same token</div>
<div>I don't want to kill my performance by running lots of different monitoring on the server.</div>
<div>Hobbit is extrodinarily lightweight on the client (as opposed to other solutions out there)</div>
<div>so I think something like this is possible without overloading a client.</div>
<div> </div>
<div>Just my two cents. </div>
<div> </div></div><br>