[
https://issues.apache.org/jira/browse/HBASE-17716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15891670#comment-15891670
]
stack commented on HBASE-17716:
-------------------------------
Hello [~karanmehta93] Can you say more about why the enum indirection route?
What are we guarding against by doing this?
It is hard for us to change metric naming. These are exported to be consumed by
operators. We can't change the names easily without pissing off folks. Is the
thought that we could have some indirection if we had enum such that phoenix
could press on if we changed a metric name? Would we then have a state where
phoenix might refer to a metric with one name but an operator looking at
metrics exported by an hbase cluster would have a different name for a metric
(if we ever changed the metric name)? Should we change all metrics to do this
indirection?
Thanks (Metric might be a better enum than MetricType given the metrics you
list count different dimensions).
> Formalize Scan Metric names
> ---------------------------
>
> Key: HBASE-17716
> URL: https://issues.apache.org/jira/browse/HBASE-17716
> Project: HBase
> Issue Type: Bug
> Components: metrics
> Reporter: Karan Mehta
> Assignee: Karan Mehta
> Priority: Minor
> Attachments: HBASE-17716.patch
>
>
> HBase provides various metrics through the API's exposed by ScanMetrics
> class.
> The JIRA PHOENIX-3248 requires them to be surfaced through the Phoenix
> Metrics API. Currently these metrics are referred via hard-coded strings,
> which are not formal and can break the Phoenix API. Hence we need to refactor
> the code to assign enums for these metrics.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
