[
https://issues.apache.org/jira/browse/HBASE-17923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Umesh Agashe updated HBASE-17923:
---------------------------------
Description:
Copied from @appy's comments in HBASE-17888:
There should be clearly defined (and well documented) points where metrics are
updated. Ideally, these points should be either single line in code and/or well
defined state (great if both).
Currently it's not well defined state, and requires hooks from multiple code
paths.
With current approach, I am afraid that it might 'evolve' like other
components, and those not much familier with this code may add more
updateMetricsOnFoo() methods from random points in exectuor.
One possible design is: Initiate all metric updates from setState() function.
That ties metrics design to a single well defined point in ProcExecutor. Also,
that way we can have:
1. updateMetricsOn<State>() functions: to update metrics on well defined states
2. update metrics on few interesting transitions. For eg.
-updateMetricsOnSubmit(): when state changes from INITIALIZING to RUNNABLE.
-updateMetricsOnFinish(): when state changes to SUCCESS or FINISH.
There should be two sets of metrics: core metrics and feature metrics.
Core metrics will include things like proc wait time, proc execute time, number
of yeilds, num subprocedures, etc
Feature metrics : Metrics like RIT metrics, snapshot metrics, etc.
Just to make sure, we are only designing for 'core metrics' and not 'feature
metrics' here right? Am confused since there are description changes for
'feature metrics' in this patch.
If we are designing for core metrics, it would be good to see actual metrics in
next patch. That would help to see if particular updateMetricsOn*() hook makes
sense.
Please refer to the discussion on that JIRA.
was:
Copied from @appy's comments in HBASE-17888:
There should be clearly defined (and well documented) points where metrics are
updated. Ideally, these points should be either single line in code and/or well
defined state (great if both).
Currently it's not well defined state, and requires hooks from multiple code
paths.
With current approach, I am afraid that it might 'evolve' like other
components, and those not much familier with this code may add more
updateMetricsOnFoo() methods from random points in exectuor.
One possible design is: Initiate all metric updates from setState() function.
That ties metrics design to a single well defined point in ProcExecutor. Also,
that way we can have:
1. updateMetricsOn<State>() functions: to update metrics on well defined states
2. update metrics on few interesting transitions. For eg.
-updateMetricsOnSubmit(): when state changes from INITIALIZING to RUNNABLE.
-updateMetricsOnFinish(): when state changes to SUCCESS or FINISH.
There should be two sets of metrics: core metrics and feature metrics.
Core metrics will include things like proc wait time, proc execute time, number
of yeilds, num subprocedures, etc
Feature metrics : Metrics like RIT metrics, snapshot metrics, etc.
Just to make sure, we are only designing for 'core metrics' and not 'feature
metrics' here right? Am confused since there are description changes for
'feature metrics' in this patch.
If we are designing for core metrics, it would be good to see actual metrics in
next patch. That would help to see if particular updateMetricsOn*() hook makes
sense.
Please refer to discussion on that JIRA.
> Provide generic framework to collect internal and feature metrics for all
> procedures in ProcV2
> ----------------------------------------------------------------------------------------------
>
> Key: HBASE-17923
> URL: https://issues.apache.org/jira/browse/HBASE-17923
> Project: HBase
> Issue Type: Improvement
> Components: metrics, proc-v2
> Reporter: Umesh Agashe
> Assignee: Umesh Agashe
>
> Copied from @appy's comments in HBASE-17888:
> There should be clearly defined (and well documented) points where metrics
> are updated. Ideally, these points should be either single line in code
> and/or well defined state (great if both).
> Currently it's not well defined state, and requires hooks from multiple code
> paths.
> With current approach, I am afraid that it might 'evolve' like other
> components, and those not much familier with this code may add more
> updateMetricsOnFoo() methods from random points in exectuor.
> One possible design is: Initiate all metric updates from setState() function.
> That ties metrics design to a single well defined point in ProcExecutor.
> Also, that way we can have:
> 1. updateMetricsOn<State>() functions: to update metrics on well defined
> states
> 2. update metrics on few interesting transitions. For eg.
> -updateMetricsOnSubmit(): when state changes from INITIALIZING to RUNNABLE.
> -updateMetricsOnFinish(): when state changes to SUCCESS or FINISH.
> There should be two sets of metrics: core metrics and feature metrics.
> Core metrics will include things like proc wait time, proc execute time,
> number of yeilds, num subprocedures, etc
> Feature metrics : Metrics like RIT metrics, snapshot metrics, etc.
> Just to make sure, we are only designing for 'core metrics' and not 'feature
> metrics' here right? Am confused since there are description changes for
> 'feature metrics' in this patch.
> If we are designing for core metrics, it would be good to see actual metrics
> in next patch. That would help to see if particular updateMetricsOn*() hook
> makes sense.
> Please refer to the discussion on that JIRA.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
