[
https://issues.apache.org/jira/browse/HBASE-18409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16129888#comment-16129888
]
Josh Elser commented on HBASE-18409:
------------------------------------
Deployed this locally and played around a bit with PE -- I'm seeing the
expected metrics client side. A little bit of cleanup, and I think this would
be good to go!
One more:
{code}
- RatioGauge executorMetrics = (RatioGauge) METRICS.getMetricRegistry()
- .getMetrics().get(METRICS.getExecutorPoolName());
- RatioGauge metaMetrics = (RatioGauge) METRICS.getMetricRegistry()
- .getMetrics().get(METRICS.getMetaPoolName());
- assertEquals(Ratio.of(0, 3).getValue(), executorMetrics.getValue(), 0);
- assertEquals(Double.NaN, metaMetrics.getValue(), 0);
+
+ // RatioGauge executorMetrics = (RatioGauge)
+ // metricsConnection.getMetricRegistry().getMetrics()
+ // .get(metricsConnection.getExecutorPoolName());
+ // RatioGauge metaMetrics = (RatioGauge)
+ // metricsConnection.getMetricRegistry().getMetrics()
+ // .get(metricsConnection.getMetaPoolName());
+ // assertEquals(Ratio.of(0, 3).getValue(), executorMetrics.getValue(), 0);
+ // assertEquals(Double.NaN, metaMetrics.getValue(), 0);
{code}
This should just be removed (not left commented out).
> Migrate Client Metrics from codahale to hbase-metrics
> -----------------------------------------------------
>
> Key: HBASE-18409
> URL: https://issues.apache.org/jira/browse/HBASE-18409
> Project: HBase
> Issue Type: Improvement
> Components: Client, java, metrics
> Affects Versions: 3.0.0
> Reporter: Ronald Macmaster
> Labels: newbie
> Fix For: 3.0.0
>
> Attachments:
> 0001-HBASE-18409-MetricsConnection-client-metrics-migration.patch,
> 0002-HBASE-18409-MetricsConnection-client-metrics-migrati.patch
>
> 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)
