[
https://issues.apache.org/jira/browse/HBASE-9774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15688574#comment-15688574
]
Enis Soztutar commented on HBASE-9774:
--------------------------------------
I created an RB for the wip patch depending on our awesome [~elserj]'s work in
Apache Calcite. It is not final, but contains almost all of the functionality
that we want:
- hbase-metrics-api is an HBase-only API that is used internally within HBase,
as well as exposed to the coprocessors. This module contains only the API part.
The API is very similar to the Dropwizard metrics API and is a subset, with
some additions for HBase. Some code is forked from
https://github.com/apache/calcite/tree/master/avatica/metrics/src/main/java/org/apache/calcite/avatica/metrics.
- hbase-metrics is an implementation of the APIs in the metrics-api module
which delegates everything to Dropwizard metrics (3.1.2) implementation. There
is also some grouping of metrics in different registries that allows to group
metrics into subcomponents (WAL, IPC, etc). This layer does not know anything
about Hadoop metrics2.
- hadoop2-compat has the Dropwizard2HadoopMetricsAdapter code that knows about
both Dropwizard based metrics and Hadoop metrics2. It can collect the metrics
in DW registries using metrics2 collectors. This is the only class that is
exposed to both of the implementations. Some code is forked from
https://github.com/joshelser/dropwizard-hadoop-metrics2.
Things that are not coming from calcite:
- MetricRegistries / GlobalMetricRegistriesSource: These are for doing
JVM-global MetricRegistry instances so that different metric registries can be
used for different subcomponents. The global source will collect all of the
metrics in all of the DW metric registries. This makes it so that we do not
have to define a lot of classes and indirection inside the actual code that
uses metrics (hbase-server, etc).
- code in hbase-server, etc will mostly use the code from hbase-metrics-api,
and do not need to know about dropwizard API and hbase-metrics implementation.
- New metric sources (like coprocessors, etc) can use only the new API, and
never have to know anything about metrics2.
- Even for existing MetricSources (like MetricsRegionServerSource), we can add
new metrics using the new API. Existing metrics can be moved to the new API
incrementally. The example bulkLoad metrics in MetricsRegionServerSource shows
how this can be used.
- The patch adds coprocessor metrics at the RS level as well as region level.
Some example code shows how to use it from coprocessors.
Review is here: https://reviews.apache.org/r/54008/
> Provide a way for coprocessors to register and report custom metrics
> --------------------------------------------------------------------
>
> Key: HBASE-9774
> URL: https://issues.apache.org/jira/browse/HBASE-9774
> Project: HBase
> Issue Type: New Feature
> Components: Coprocessors, metrics
> Reporter: Gary Helmling
>
> It would help provide better visibility into what coprocessors are doing if
> we provided a way for coprocessors to export their own metrics. The general
> idea is to:
> * extend access to the HBase "metrics bus" down into the coprocessor
> environments
> * coprocessors can then register and increment custom metrics
> * coprocessor metrics are then reported along with all others through normal
> mechanisms
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
