You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Ronald Macmaster (JIRA)" <ji...@apache.org> on 2017/07/19 00:23:03 UTC
[jira] [Updated] (HBASE-18409) Migrate Client Metrics from codahale
to hbase-metrics
[ https://issues.apache.org/jira/browse/HBASE-18409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ronald Macmaster updated HBASE-18409:
-------------------------------------
Description:
Currently, the metrics for hbase-client are tailored for reporting via a client-side JMX server.
The MetricsConnection handles the metrics management and reporting via the metrics platform from codahale.
This approach worked well for hbase-1.3.1 when the metrics platform was still relatively young, but it could be improved by using the new hbase-metrics-api.
Now that we have an actual hbase-metrics-api that master, regionserver, zookeeper, and other daemons use, it would be good to also allow the client to leverage the metrics-api.
Then, the client could also report its metrics via Hadoop's metrics2 if desired or through another platform that utilizes the hbase-metrics-api.
If left alone, client metrics will continue to be only barely visible through a client-side JMX server.
The migration to the new metrics-api could be done by simply changing the Metrics data types from codahale types to hbase-metrics types without changing the metrics signatures of MetricsConnection unless completely necessary.
The codahale MetricsRegistry would also have to be exchanged for a hbase-metrics MetricsRegistry.
I found this to be a necessary change after attempting to implement my own Reporter to use within the MetricsConnection class.
I was attempting to create a HadoopMetrics2Reporter that extends the codahale ScheduledReporter and reports the MetricsConnection metrics to Hadoop's metrics2 system.
The already existing infrastructure in the hbase-metrics and hbase-metrics-api projects could be easily leveraged for a cleaner solution.
If completed successfully, users could instead access their client-side metrics through the hbase-metrics-api.
was:
Currently, the metrics for hbase-client are tailored for reporting via a client-side JMX server.
The MetricsConnection handles the metrics management and reporting via the metrics platform from codahale. This approach worked well for hbase-1.3.1 when the metrics platform was still relatively young, but it could be improved by using the new hbase-metrics-api.
However, now that we have an actual hbase-metrics-api that master, regionserver, zookeeper, and others use, it would be good to also allow the client to leverage the metrics-api. Then, the client could also report its metrics via Hadoop's metrics2 if desired or through another platform that utilizes the hbase-metrics-api. If left alone, client metrics will continue to be only barely visible through a client-side JMX server.
The migration to the new metrics-api could be done by simply changing the Metrics data types from codahale types to hbase-metrics types without changing the metrics signatures of MetricsConnection unless completely necessary. The codahale MetricsRegistry would also have to be exchanged for a hbase-metrics MetricsRegistry.
> Migrate Client Metrics from codahale to hbase-metrics
> -----------------------------------------------------
>
> Key: HBASE-18409
> URL: https://issues.apache.org/jira/browse/HBASE-18409
> Project: HBase
> Issue Type: Bug
> Components: Client, java, metrics
> Affects Versions: 2.0.0-alpha-1
> Reporter: Ronald Macmaster
> Labels: newbie
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Currently, the metrics for hbase-client are tailored for reporting via a client-side JMX server.
> The MetricsConnection handles the metrics management and reporting via the metrics platform from codahale.
> This approach worked well for hbase-1.3.1 when the metrics platform was still relatively young, but it could be improved by using the new hbase-metrics-api.
> Now that we have an actual hbase-metrics-api that master, regionserver, zookeeper, and other daemons use, it would be good to also allow the client to leverage the metrics-api.
> Then, the client could also report its metrics via Hadoop's metrics2 if desired or through another platform that utilizes the hbase-metrics-api.
> If left alone, client metrics will continue to be only barely visible through a client-side JMX server.
> The migration to the new metrics-api could be done by simply changing the Metrics data types from codahale types to hbase-metrics types without changing the metrics signatures of MetricsConnection unless completely necessary.
> The codahale MetricsRegistry would also have to be exchanged for a hbase-metrics MetricsRegistry.
> I found this to be a necessary change after attempting to implement my own Reporter to use within the MetricsConnection class.
> I was attempting to create a HadoopMetrics2Reporter that extends the codahale ScheduledReporter and reports the MetricsConnection metrics to Hadoop's metrics2 system.
> The already existing infrastructure in the hbase-metrics and hbase-metrics-api projects could be easily leveraged for a cleaner solution.
> If completed successfully, users could instead access their client-side metrics through the hbase-metrics-api.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)