Good point Gordon, I was thinking the # of open scanners/mutators would serve that purpose, but as you point out I should really have another counter for # of opened scanners/mutators since the last "dump stats" command.
Also the master will store per server and per table stats in something like RRDTool <http://oss.oetiker.ch/rrdtool/index.en.html>, so that should provide a sliding window of historical data. -Sanjit On Mon, Apr 12, 2010 at 3:05 PM, Gordon <[email protected]> wrote: > Looks good ... one point is that for any of the aggregate stats (rates, > avg, min, max) it's always good to have a sample size or number of > observations since a average (or equivalently a rate for binary data) based > on a small number of points is very different than for larger samples. This > is especially true for the process control view of the system that looks at > trends in these stats over a window of several periods. > > On Mon, Apr 12, 2010 at 7:15 PM, Sanjit Jhala <[email protected]> wrote: > >> One of the features we intend to add to release 0.9.4.0 is a monitoring >> system. >> The general idea is that the master will periodically issue something like >> a "dump stats" command to the RangeServers and collect the responses. >> The data collected will be used to make load balancing/range >> re-distribution decisions as well as exposed via the monitoring interface so >> that admins can monitor the health of the Hypertable cluster. >> The Master can rollup stats to a per-RangeServer and per-table level since >> that will probably make the most sense from a health check point of view. >> >> I propose the following list of *per RangeServer stats:* >> -#ranges >> -cpu load >> -memory usage >> -disk stats >> -network stats >> -block cache size >> -query cache size >> -#open file handles >> -block cache hit rate >> -query cache hit rate >> >> as well as a set of *per Range stats*: >> -name/range id >> -qps , bytes read per sec >> -writes/s , bytes written/s >> -#open scanners >> -(min, max, avg) scanner lifetimes >> -#open mutators >> -(min, max, avg) mutator lifetimes >> >> Any thoughts on other useful stats for the monitoring console, range >> balancing or on the monitoring framework in general would be very welcome. >> >> -Sanjit >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Hypertable Development" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<hypertable-dev%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/hypertable-dev?hl=en. >> > > > > -- > Gordon Rios -- Cork Constraint Computation Centre > http://www.4c.ucc.ie/web/people.jsp?id=144 > http://www.linkedin.com/in/gordonrios > > -- > You received this message because you are subscribed to the Google Groups > "Hypertable Development" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<hypertable-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/hypertable-dev?hl=en. > -- You received this message because you are subscribed to the Google Groups "Hypertable Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/hypertable-dev?hl=en.
