[
https://issues.apache.org/jira/browse/HBASE-11062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314835#comment-16314835
]
Andrew Purtell commented on HBASE-11062:
----------------------------------------
While debugging elevated meta query rates we've noticed how clunky it is to do
that right now. In order to find top-N accesses by client identity or by table
name you have to toggle RpcServer to TRACE (only for a short time!), scrape the
resulting log output, extract via regex, rinse and repeat. It becomes apparent
a special set of metrics for the meta region, counting queries for particular
tables and by client identity, would be useful. Although this JIRA is scoped to
be a lot more than this, meta query statistics would be a good start. This
doesn't require any cross cluster (partial) aggregation and communication.
Whatever server hosting meta can create a special mbean for tracking meta
request stats. This information would be picked up by whatever monitoring
solution is already in place. I'll file a subtask for this.
> htop
> ----
>
> Key: HBASE-11062
> URL: https://issues.apache.org/jira/browse/HBASE-11062
> Project: HBase
> Issue Type: New Feature
> Reporter: Andrew Purtell
> Assignee: Andrew Purtell
> Labels: beginner
>
> A top-like monitor could be useful for testing, debugging, operations of
> clusters of moderate size, and possibly for diagnosing issues in large
> clusters.
> Consider a curses interface like the one presented by atop
> (http://www.atoptool.nl/images/screenshots/genericw.png) - with aggregate
> metrics collected over a monitoring interval in the upper portion of the
> pane, and a listing of discrete measurements sorted and filtered by various
> criteria in the bottom part of the pane. One might imagine a cluster overview
> with cluster aggregate metrics above and a list of regionservers sorted by
> utilization below; and a regionserver view with process metrics above and a
> list of metrics by operation type below, or a list of client connections, or
> a list of threads, sorted by utilization, throughput, or latency.
> Generically 'htop' is taken but would be distinctive in the HBase context, a
> utility org.apache.hadoop.hbase.HTop
> No need necessarily for a curses interface. Could be an external monitor with
> a web front end as has been discussed before. I do like the idea of a process
> that runs in a terminal because I interact with dev and test HBase clusters
> exclusively by SSH.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
