hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@gmail.com>
Subject Re: Coprocessor metrics
Date Mon, 14 Nov 2016 05:38:51 GMT
IIRC, the plan is to get off of Hadoop Metrics2, so I am in favor of either
(2) or (3). Specifically for (3), I believe there is an implementation for
translating Dropwizard Metrics to Hadoop Metrics2, in or around Avatica
and/or Phoenix Query Server.

On Fri, Nov 11, 2016 at 3:15 PM, Enis Söztutar <enis@apache.org> wrote:

> HBase / Phoenix devs,
> I would like to solicit early feedback on the design approach that we would
> pursue for exposing coprocessor metrics. It has implications for our
> compatibility, so lets try to have some consensus. Added Phoenix devs as
> well since this will affect how coprocessors can emit metrics via region
> server metrics bus.
> The issue is HBASE-9774 [1].
> We have a couple of options:
> (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) especially with Yammer
> metrics 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?
> [1] https://issues.apache.org/jira/browse/HBASE-9774

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message