[
https://issues.apache.org/jira/browse/HBASE-9774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15655652#comment-15655652
]
Enis Soztutar commented on HBASE-9774:
--------------------------------------
I would like to take on this work so that coprocessors can export their
internal state.
One big question that we have to decide though is the API that we expose to the
coprocessors. We have a couple of options, and I would like to have some
feedback and consensus before starting the implementation:
(1) Expose Hadoop Metrics2 + HBase internal classes (like BaseSourceImpl,
MutableFastCounter, FastLongHistogram, etc). This option is the least amount of
work in terms of defining the API. We would mark the important classes with
{{LimitedPrivate(Coprocessor)}} and have the coprocessors each write their
metrics source classes separately. The disadvantage would be that some of the
internal APIs are now public and has to be evolved with regards to coprocessor
API compatibility. Also it will make it so that breaking coprocessors are now
easier across minor releases.
(2) Build a Metrics subset API in HBase to abstract away HBase metrics classes
and Hadoop2 metrics classes and expose this API only. The API will probably be
limited and will be a small subset. HBase internals do not need to be changed
that much, but the API has to be kept {{LimitedPrivate(Coprocessor)}} with the
compatibility implications.
(3) Expose (a limited subset of) third-party API to the coprocessors (like
Yammer metrics) and never expose internal HBase / Hadoop implementation. Build
a translation layer between the yammer metrics and our Hadoop metrics 2
implementation so that things will still work. If we end up changing the
implementation, existing coprocessors will not be affected. The downside is
that whatever API that we agree to expose becomes our compatibility point. We
cannot change that dependency version unless it is acceptable via our
compatibility guidelines.
Personally, I would like to pursue option (3) since we do not have to build yet
another API endpoint. Hadoop's metrics API is not the best and we do not know
whether we will end up changing that dependency. What do you guys think?
> 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)
