[
https://issues.apache.org/jira/browse/HBASE-19722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16491066#comment-16491066
]
Andrew Purtell edited comment on HBASE-19722 at 5/25/18 5:43 PM:
-----------------------------------------------------------------
bq. Lossy counting algorithm designed the sweeping happens every "1 /
errorRate" items arrived. For example, if e is 0.02, sweep() method will be
called every 50 times.
It's still done inline with the metrics update. How expensive is the sweep? If
done from a chore in another thread the average work per update would be less,
but I suppose there would be locking while the sweep happens, so never mind.
Thanks.
350 might be more than an operator would want. We don't have a precise
definition for what would be a manageable number of counters because it would
be a matter of opinion. 100 would be fine IMHO, 1000 not so much. Just some
numbers I made up right now thinking about scraping the JMX directly. If an
operator would query this information from an external metrics DB, they could
sort and cut the list with the DB's query tools, so it doesn't really matter
for those poeple. Need to consider others who might process the raw JMX data,
though.
was (Author: apurtell):
bq. Lossy counting algorithm designed the sweeping happens every "1 /
errorRate" items arrived. For example, if e is 0.02, sweep() method will be
called every 50 times.
It's still done inline with the metrics update. How expensive is the sweep? Was
thinking if done from a chore in another thread the average work per update
would be less, but I suppose there would be locking while the sweep happens, so
never mind. Thanks.
350 might be more than an operator would want. We don't have a precise
definition for what would be a manageable number of counters because it would
be a matter of opinion. 100 would be fine IMHO, 1000 not so much. Just some
numbers I made up right now thinking about scraping the JMX directly. If an
operator would query this information from an external metrics DB, they could
sort and cut the list with the DB's query tools, so it doesn't really matter
for those poeple. Need to consider others who might process the raw JMX data,
though.
> Implement a meta query statistics metrics source
> ------------------------------------------------
>
> Key: HBASE-19722
> URL: https://issues.apache.org/jira/browse/HBASE-19722
> Project: HBase
> Issue Type: Sub-task
> Reporter: Andrew Purtell
> Assignee: Xu Cang
> Priority: Major
> Attachments: HBASE-19722.branch-1.v001.patch,
> HBASE-19722.master.010.patch, HBASE-19722.master.011.patch,
> HBASE-19722.master.012.patch, HBASE-19722.master.013.patch
>
>
> Implement a meta query statistics metrics source, created whenever a
> regionserver starts hosting meta, removed when meta hosting moves. Provide
> views on top tables by request counts, top meta rowkeys by request count, top
> clients making requests by their hostname.
> Can be implemented as a coprocessor.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
