hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elliott Clark (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14082) Add replica id to JMX metrics names
Date Wed, 15 Jul 2015 22:39:04 GMT

    [ https://issues.apache.org/jira/browse/HBASE-14082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628884#comment-14628884
] 

Elliott Clark commented on HBASE-14082:
---------------------------------------

bq.Is there any explicit stability promised for the JMX paths too to understand what options
are open for addition of this data?
We've treated it as a breaking change before.  Transition from metrics1 to metrics2

bq.Elliott Clark the intention is to provide a way one can get region metrics rolled up by
region server, region, replica, etc. putting it in another bean would not provide the desired
region metrics differentiation by primary/secondary without having to replicate the whole
bean. 
Sure there is. Have a bean that specifies which replica id this regionserver is hosting (
a region server can't host more than one replica of a region). Then when you poll jmx just
join the metrics parsed from per region metrics with the replica id.

bq.Also, can you elaborate on how the addition of the replica ID would break your monitoring?
Internally we have a parser. I know there's also a tsdb tcollector that has the parsing. Pretty
sure that other vendors also have the same.

> Add replica id to JMX metrics names
> -----------------------------------
>
>                 Key: HBASE-14082
>                 URL: https://issues.apache.org/jira/browse/HBASE-14082
>             Project: HBase
>          Issue Type: Improvement
>          Components: metrics
>            Reporter: Lei Chen
>            Assignee: Lei Chen
>         Attachments: HBASE-14082-v1.patch
>
>
> Today, via JMX, one cannot distinguish a primary region from a replica. A possible solution
is to add replica id to JMX metrics names. The benefits may include, for example:
> # Knowing the latency of a read request on a replica region means the first attempt to
the primary region has timeout.
> # Write requests on replicas are due to the replication process, while the ones on primary
are from clients.
> # In case of looking for hot spots of read operations, replicas should be excluded since
TIMELINE reads are sent to all replicas.
> To implement, we can change the format of metrics names found at {code}Hadoop->HBase->RegionServer->Regions->Attributes{code}
> from 
> {code}namespace_<namespace>_table_<tablename>_region_<regionname>_metric_<metricname>{code}
> to
> {code}namespace_<namespace>_table_<tablename>_region_<regionname>_replicaid_<replicaid>_metric_<metricname>{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message