[jira] [Comment Edited] (HBASE-27681) Refactor Table Latency Metrics

["tianhang tang (Jira)" <ji...@apache.org>]

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

tianhang tang edited comment on HBASE-27681 at 3/14/23 10:34 AM:
-----------------------------------------------------------------

Paste some discusses in PR here:

 

{quote}


From the naming point of view, MetricsRegionServer and MetricsTableRequests should be at the same level, but they are actually completely different. We can see that MetricsRegionServer holds serverSource, metricsTable, tableMetrics, userAggregate, and so on.

My vision is that each metrics object is only responsible for operating one type of metrics (that is, a bean in jmx), so that the metric of the table belongs to the metricsTable, the metric of the server belongs to the metricsServer, and the metric of the region belongs to the metricsRegion. Then there is a tool class that only needs to be called once externally (such as in RSRpcServices), and encapsulates all operations on metrics in the methods of this tool class.

In fact, the current MetricsRegionServer is such a tool class. We can change its name, or create a new class, and then gradually refactor various metrics, transfer the function of the main entrance to the new class, and let MetricsRegionServer gradually degenerate into only responsible for serverMetrics.


{quote}

 

Will try to do some metric refactor work in the future.


was (Author: tangtianhang):
Paste some discusses in PR here:

 

{{{quote}}}

{{{}{}}}From the naming point of view, MetricsRegionServer and MetricsTableRequests should be at the same level, but they are actually completely different. We can see that MetricsRegionServer holds serverSource, metricsTable, tableMetrics, userAggregate, and so on.

{{}}

{{}}

My vision is that each metrics object is only responsible for operating one type of metrics (that is, a bean in jmx), so that the metric of the table belongs to the metricsTable, the metric of the server belongs to the metricsServer, and the metric of the region belongs to the metricsRegion. Then there is a tool class that only needs to be called once externally (such as in RSRpcServices), and encapsulates all operations on metrics in the methods of this tool class.

{{}}

In fact, the current MetricsRegionServer is such a tool class. We can change its name, or create a new class, and then gradually refactor various metrics, transfer the function of the main entrance to the new class, and let MetricsRegionServer gradually degenerate into only responsible for serverMetrics.

{{}}

{{}}

{{{}{}}}{{{}{quote}{}}}

{{}}

Will try to do some metric refactor work in the future.{{{}{}}}

{{}}

> Refactor Table Latency Metrics
> ------------------------------
>
>                 Key: HBASE-27681
>                 URL: https://issues.apache.org/jira/browse/HBASE-27681
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: tianhang tang
>            Assignee: tianhang tang
>            Priority: Major
>             Fix For: 2.6.0, 3.0.0-alpha-4
>
>         Attachments: image-2023-03-01-23-55-14-095.png, image-2023-03-01-23-56-16-819.png
>
>
> Benefit:
>  # Table Latency Metrics could removed after table has been moved away. Fix HBASE-27617
>  # Could remove the hash lookup caused by metrics map from the hot request path.
>  # Reduce the output in jmx. As if we use jmx_exporter to collect metrics to Prometheus, the operation overhead of performing regular matching in metric is relatively high(especially region metrics, which might be next step).
>  # I think that could be the first step after hbase-metrics released. It seems that the roadmap indicates that we should replace directly use hadoop-metrics2 with hbase-metrics.
> Influence:
>  # The metrics structure in jmx will change.
> Old:
> !image-2023-03-01-23-55-14-095.png|width=450,height=407! 
> New:
> !image-2023-03-01-23-56-16-819.png|width=615,height=479!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)