Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 13 Apr 2017 21:43:41 +0000 (UTC)
From: "Umesh Agashe (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13062255.1491515082000.279876.1492119821655@Atlassian.JIRA>
In-Reply-To: <JIRA.13062255.1491515082000@Atlassian.JIRA>
References: <JIRA.13062255.1491515082000@Atlassian.JIRA> <JIRA.13062255.1491515082529@jira-lw-us.apache.org>
Subject: [jira] [Comment Edited] (HBASE-17888) Add generic methods for
 updating metrics on start and end of a procedure execution
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 13 Apr 2017 21:43:48 -0000


    [ 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)