Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
MIME-Version: 1.0
From: =?UTF-8?Q?Enis_S=C3=B6ztutar?= <enis@apache.org>
Date: Fri, 11 Nov 2016 15:15:54 -0800
Message-ID: <CAMUu0w-WsqtFFaNR-1rkmMiADEAUtWW2=zkFYdKHFm76S9taRg@mail.gmail.com>
Subject: Coprocessor metrics
To: "dev@hbase.apache.org" <dev@hbase.apache.org>, "dev@phoenix.apache.org" <dev@phoenix.apache.org>
Content-Type: multipart/alternative; boundary=001a1143e08e30386a05410ead2c
archived-at: Fri, 11 Nov 2016 23:16:17 -0000

--001a1143e08e30386a05410ead2c
Content-Type: text/plain; charset=UTF-8

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

--001a1143e08e30386a05410ead2c--