hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Umesh Agashe (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-17888) Add generic methods for updating metrics on start and end of a procedure execution
Date Thu, 13 Apr 2017 21:43:41 GMT

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

Umesh Agashe edited comment on HBASE-17888 at 4/13/17 9:42 PM:
---------------------------------------------------------------

[~appy], thank you for writing down the summary of the feature in your comments on review
board and posting it here. I think, it correctly captures the idea behind the feature. When
I started working on HBASE-16549, I started looking into how we can effectively collect metrics
for assignment manager and found that there is a generic way we can collect metrics for all
procedures. Here are my thoughts:

#1
I agree with most what you say here. The approach that I took here is to do whats necessary
to complete HBASE-16549 and later revisit ProcV2 refactoring to work on broader feature. If
later gets delayed or didn't get done for some reason then I share your concern about updateMetricsOn<Something>
will be at multiple random points. That will not be good.

#2
Having updateMetricsOn<State> method for every state; for it work we need to consider
following:
* What internal and external states are of interest to collect metrics (both core metric and
feature metric as you have mentioned in #3)
* Currently as procedure is waiting_in_queue is not exposed outside, I think hooks for updateMetricsOnSubmit()
and updateMetricsOnFinish() are of more interest for collecting feature metric.

#3
Regarding core metric:
* I also think collecting the metric on the time procedure spends waiting in queue is worth
collecting. One way to implement it is through adding one more state to track it. Collecting
metric about other waiting states (WAITING and WAITING_TIMEOUT) can be considered later (based
on need).

I understand the general concern here that current code changes doesn't reflect this. The
narrower feature HBASE-16549 needs broader feature which is not implemented yet and will be
implemented later. Current patch only has partial changes required for HBASE-16549.

I am working on the patch based on the latest review comments. I will submit it when its ready.
Let me know your thoughts.

Thanks, Umesh
 


was (Author: uagashe):
[~appy], thank you for writing down the summary of the feature in your comments on review
board and posting it here. I think, it correctly captures the idea behind the feature. When
I started working on HBASE-16549, I started looking into how we can effectively collect metrics
for assignment manager and found that there is a generic way we can collect metrics for all
procedures. Here are my thoughts:

#1
I agree with most what you say here. The approach that I took here is to do whats necessary
to complete HBASE-16549 and later revisit ProcV2 refactoring to work on broader feature. If
later gets delayed or didn't get done for some reason then I share your concern about updateMetricsOn<Something>
will be at multiple random points. That will not be good.

#2
Having updateMetricsOn<State> method for every state; for it work we need to consider
following:
* What internal and external states are of interest to collect metrics (both core metric and
feature metric as you have mentioned in #3)
* Currently as procedure is waiting_in_queue is not exposed outside, I think hooks for updateMetricsOnSubmit()
and updateMetricsOnFinish() are of more interest for collecting feature metric.

#3
* I also think collecting the metric on the time procedure spends waiting in queue is worth
collecting. One way to implement it is through adding one more state to track it. Collecting
metric about other waiting states (WAITING and WAITING_TIMEOUT) can be considered later (based
on need).

I understand the general concern here that current code changes doesn't reflect this. The
narrower feature HBASE-16549 needs broader feature which is not implemented yet and will be
implemented later. Current patch only has partial changes required for HBASE-16549.

I am working on the patch based on the latest review comments. I will submit it when its ready.
Let me know your thoughts.

Thanks, Umesh
 

> Add generic methods for updating metrics on start and end of a procedure execution
> ----------------------------------------------------------------------------------
>
>                 Key: HBASE-17888
>                 URL: https://issues.apache.org/jira/browse/HBASE-17888
>             Project: HBase
>          Issue Type: Improvement
>          Components: proc-v2
>            Reporter: Umesh Agashe
>            Assignee: Umesh Agashe
>         Attachments: HBASE-17888.v1.patch, HBASE-17888.v2.patch
>
>
> For all procedures in Procv2 framework, Procedure class can have generic methods to update
metrics on start and end of a procedure execution. Specific procedure can override these and
implement/ update respective metrics. Default implementation needs to be provided so override
and implementation is optional.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message