Coprocessor metrics

[Enis Söztutar <en...@apache.org>]

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

Re: Coprocessor metrics

[Andrew Purtell <ap...@apache.org>]

+1

We also need to get away from Guava's Service interface for replication
endpoint plugins using this same approach (#2): HBASE-15982

On Mon, Nov 14, 2016 at 10:37 AM, Gary Helmling <gh...@gmail.com> wrote:

> >
> >
> > My current feeling is that external API should never include
> > classes/interfaces which you don't "own". Re-building the API that
> > already exists is pedantic, but I think it's a really good way to pay
> > down the maintenance debt (whenever the next metrics library "hotness"
> > takes off).
> >
> >
> +1 to this.  I'd be very hesitant to tie ourselves too strongly to a
> specific implementation, even if it is just copying an interface.
>
> For coprocessors specifically, I think we can start with a limited API
> exposing common metric types and evolve it from there.  But starting simple
> seems key.
>
> So #2 seems like the right approach to me.
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Coprocessor metrics

[Andrew Purtell <ap...@apache.org>]

+1

We also need to get away from Guava's Service interface for replication
endpoint plugins using this same approach (#2): HBASE-15982

On Mon, Nov 14, 2016 at 10:37 AM, Gary Helmling <gh...@gmail.com> wrote:

> >
> >
> > My current feeling is that external API should never include
> > classes/interfaces which you don't "own". Re-building the API that
> > already exists is pedantic, but I think it's a really good way to pay
> > down the maintenance debt (whenever the next metrics library "hotness"
> > takes off).
> >
> >
> +1 to this.  I'd be very hesitant to tie ourselves too strongly to a
> specific implementation, even if it is just copying an interface.
>
> For coprocessors specifically, I think we can start with a limited API
> exposing common metric types and evolve it from there.  But starting simple
> seems key.
>
> So #2 seems like the right approach to me.
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Coprocessor metrics

[Gary Helmling <gh...@gmail.com>]

>
>
> My current feeling is that external API should never include
> classes/interfaces which you don't "own". Re-building the API that
> already exists is pedantic, but I think it's a really good way to pay
> down the maintenance debt (whenever the next metrics library "hotness"
> takes off).
>
>
+1 to this.  I'd be very hesitant to tie ourselves too strongly to a
specific implementation, even if it is just copying an interface.

For coprocessors specifically, I think we can start with a limited API
exposing common metric types and evolve it from there.  But starting simple
seems key.

So #2 seems like the right approach to me.

Re: Coprocessor metrics

[Josh Elser <jo...@gmail.com>]

Enis S�ztutar wrote:
> Bumping this up in case people are interested.
>
> Also this is not coprocessor-specific, because I think we can incrementally
> start using the new hbase-metrics module, and get rid of our complicated
> metrics2 based patterns for core metrics as well. We should of course start
> enforcing that all new metrics be using the new approach (if there is
> consensus).  See HBASE-14282.
>
> I've uploaded a v1 patch for
> https://issues.apache.org/jira/browse/HBASE-9774. It is a mix between
> approach (2) and (3). The API looks like the DW metrics (with still some
> differences), but the implementations mostly come from HBase (except for
> Meter).
>
> @Phoenix devs, feel free to provide feedback if you intend to export
> metrics from Phoenix by piggy backing on the RS metrics.

Would definitely like to play around with this from the Phoenix side, 
but I probably won't get any time for a week or two :). I'll try to 
remember to send a note when I find the time.

 From the HBase side, the code looks good to me, but I don't want to you 
to wait for me to merge it in :)

> Enis

Re: Coprocessor metrics

[Josh Elser <jo...@gmail.com>]

Enis S�ztutar wrote:
> Bumping this up in case people are interested.
>
> Also this is not coprocessor-specific, because I think we can incrementally
> start using the new hbase-metrics module, and get rid of our complicated
> metrics2 based patterns for core metrics as well. We should of course start
> enforcing that all new metrics be using the new approach (if there is
> consensus).  See HBASE-14282.
>
> I've uploaded a v1 patch for
> https://issues.apache.org/jira/browse/HBASE-9774. It is a mix between
> approach (2) and (3). The API looks like the DW metrics (with still some
> differences), but the implementations mostly come from HBase (except for
> Meter).
>
> @Phoenix devs, feel free to provide feedback if you intend to export
> metrics from Phoenix by piggy backing on the RS metrics.

Would definitely like to play around with this from the Phoenix side, 
but I probably won't get any time for a week or two :). I'll try to 
remember to send a note when I find the time.

 From the HBase side, the code looks good to me, but I don't want to you 
to wait for me to merge it in :)

> Enis

Re: Coprocessor metrics

[Enis Söztutar <en...@apache.org>]

Bumping this up in case people are interested.

Also this is not coprocessor-specific, because I think we can incrementally
start using the new hbase-metrics module, and get rid of our complicated
metrics2 based patterns for core metrics as well. We should of course start
enforcing that all new metrics be using the new approach (if there is
consensus).  See HBASE-14282.

I've uploaded a v1 patch for
https://issues.apache.org/jira/browse/HBASE-9774. It is a mix between
approach (2) and (3). The API looks like the DW metrics (with still some
differences), but the implementations mostly come from HBase (except for
Meter).

@Phoenix devs, feel free to provide feedback if you intend to export
metrics from Phoenix by piggy backing on the RS metrics.

Enis


On Mon, Nov 14, 2016 at 12:22 PM, Enis Söztutar <en...@gmail.com> wrote:

> Thanks everyone, this is really helpful. If we can leverage the work
> already Josh/Nick did in Avatica in HBase that will be really good.
>
> Seems that the consensus is to follow #2 approach, and pay the price at
> replicating the API layer in HBase for the convenience of coprocessors and
> not to tie ourselves with a third party API + implementation.
>
> However, even if we do an avatica release, HBase depending on metrics API
> in Avatica is the same thing as HBase depending on dropwizard directly
> since HBase does not "control" the Avatica API either. At this point
> blindly forking the code inside HBase seems like the way to go (possibly in
> it's own module).
>
> Let me poke around, and fork the code if possible inside HBase. I'll send
> reviews your way.
>
> Enis
>
> On Mon, Nov 14, 2016 at 7:58 AM, Josh Elser <el...@apache.org> wrote:
>
>> Yep -- see avatica-metrics[1], avatica-dropwizard-metrics3[2], and my
>> dropwizard-hadoop-metrics2[3] project for what Nick is referring to.
>>
>> What I ended up doing in Calcite/Avatica was a step beyond your #3, Enis.
>> Instead of choosing a subset of some standard metrics library to expose, I
>> "re-built" the actual API that I wanted to expose. At the end of the day,
>> the API I "built" was nearly 100% what dropwizard metrics' API was. I like
>> the dropwizard-metrics API; however, we wanted to avoid the strong coupling
>> to a single metrics implementation.
>>
>> My current feeling is that external API should never include
>> classes/interfaces which you don't "own". Re-building the API that already
>> exists is pedantic, but I think it's a really good way to pay down the
>> maintenance debt (whenever the next metrics library "hotness" takes off).
>>
>> If it's amenable to you, Enis, I'm happy to work with you to do whatever
>> decoupling of this metrics abstraction away from the "core" of Avatica
>> (e.g. presently, a new update of the library would also require a full
>> release of Avatica which is no-good for HBase). I think a lot of the
>> lifting I've done already would be reusable by you and help make a better
>> product at the end of the day.
>>
>> - Josh
>>
>> [1] https://github.com/apache/calcite/tree/master/avatica/metrics
>> [2] https://github.com/apache/calcite/tree/master/avatica/metric
>> s-dropwizardmetrics3
>> [3] https://github.com/joshelser/dropwizard-hadoop-metrics2
>>
>>
>> Nick Dimiduk wrote:
>>
>>> 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<en...@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
>>>>
>>>>
>>>
>

Re: Coprocessor metrics

[Enis Söztutar <en...@apache.org>]

Bumping this up in case people are interested.

Also this is not coprocessor-specific, because I think we can incrementally
start using the new hbase-metrics module, and get rid of our complicated
metrics2 based patterns for core metrics as well. We should of course start
enforcing that all new metrics be using the new approach (if there is
consensus).  See HBASE-14282.

I've uploaded a v1 patch for
https://issues.apache.org/jira/browse/HBASE-9774. It is a mix between
approach (2) and (3). The API looks like the DW metrics (with still some
differences), but the implementations mostly come from HBase (except for
Meter).

@Phoenix devs, feel free to provide feedback if you intend to export
metrics from Phoenix by piggy backing on the RS metrics.

Enis


On Mon, Nov 14, 2016 at 12:22 PM, Enis Söztutar <en...@gmail.com> wrote:

> Thanks everyone, this is really helpful. If we can leverage the work
> already Josh/Nick did in Avatica in HBase that will be really good.
>
> Seems that the consensus is to follow #2 approach, and pay the price at
> replicating the API layer in HBase for the convenience of coprocessors and
> not to tie ourselves with a third party API + implementation.
>
> However, even if we do an avatica release, HBase depending on metrics API
> in Avatica is the same thing as HBase depending on dropwizard directly
> since HBase does not "control" the Avatica API either. At this point
> blindly forking the code inside HBase seems like the way to go (possibly in
> it's own module).
>
> Let me poke around, and fork the code if possible inside HBase. I'll send
> reviews your way.
>
> Enis
>
> On Mon, Nov 14, 2016 at 7:58 AM, Josh Elser <el...@apache.org> wrote:
>
>> Yep -- see avatica-metrics[1], avatica-dropwizard-metrics3[2], and my
>> dropwizard-hadoop-metrics2[3] project for what Nick is referring to.
>>
>> What I ended up doing in Calcite/Avatica was a step beyond your #3, Enis.
>> Instead of choosing a subset of some standard metrics library to expose, I
>> "re-built" the actual API that I wanted to expose. At the end of the day,
>> the API I "built" was nearly 100% what dropwizard metrics' API was. I like
>> the dropwizard-metrics API; however, we wanted to avoid the strong coupling
>> to a single metrics implementation.
>>
>> My current feeling is that external API should never include
>> classes/interfaces which you don't "own". Re-building the API that already
>> exists is pedantic, but I think it's a really good way to pay down the
>> maintenance debt (whenever the next metrics library "hotness" takes off).
>>
>> If it's amenable to you, Enis, I'm happy to work with you to do whatever
>> decoupling of this metrics abstraction away from the "core" of Avatica
>> (e.g. presently, a new update of the library would also require a full
>> release of Avatica which is no-good for HBase). I think a lot of the
>> lifting I've done already would be reusable by you and help make a better
>> product at the end of the day.
>>
>> - Josh
>>
>> [1] https://github.com/apache/calcite/tree/master/avatica/metrics
>> [2] https://github.com/apache/calcite/tree/master/avatica/metric
>> s-dropwizardmetrics3
>> [3] https://github.com/joshelser/dropwizard-hadoop-metrics2
>>
>>
>> Nick Dimiduk wrote:
>>
>>> 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<en...@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
>>>>
>>>>
>>>
>

Re: Coprocessor metrics

[Enis Söztutar <en...@gmail.com>]

Thanks everyone, this is really helpful. If we can leverage the work
already Josh/Nick did in Avatica in HBase that will be really good.

Seems that the consensus is to follow #2 approach, and pay the price at
replicating the API layer in HBase for the convenience of coprocessors and
not to tie ourselves with a third party API + implementation.

However, even if we do an avatica release, HBase depending on metrics API
in Avatica is the same thing as HBase depending on dropwizard directly
since HBase does not "control" the Avatica API either. At this point
blindly forking the code inside HBase seems like the way to go (possibly in
it's own module).

Let me poke around, and fork the code if possible inside HBase. I'll send
reviews your way.

Enis

On Mon, Nov 14, 2016 at 7:58 AM, Josh Elser <el...@apache.org> wrote:

> Yep -- see avatica-metrics[1], avatica-dropwizard-metrics3[2], and my
> dropwizard-hadoop-metrics2[3] project for what Nick is referring to.
>
> What I ended up doing in Calcite/Avatica was a step beyond your #3, Enis.
> Instead of choosing a subset of some standard metrics library to expose, I
> "re-built" the actual API that I wanted to expose. At the end of the day,
> the API I "built" was nearly 100% what dropwizard metrics' API was. I like
> the dropwizard-metrics API; however, we wanted to avoid the strong coupling
> to a single metrics implementation.
>
> My current feeling is that external API should never include
> classes/interfaces which you don't "own". Re-building the API that already
> exists is pedantic, but I think it's a really good way to pay down the
> maintenance debt (whenever the next metrics library "hotness" takes off).
>
> If it's amenable to you, Enis, I'm happy to work with you to do whatever
> decoupling of this metrics abstraction away from the "core" of Avatica
> (e.g. presently, a new update of the library would also require a full
> release of Avatica which is no-good for HBase). I think a lot of the
> lifting I've done already would be reusable by you and help make a better
> product at the end of the day.
>
> - Josh
>
> [1] https://github.com/apache/calcite/tree/master/avatica/metrics
> [2] https://github.com/apache/calcite/tree/master/avatica/metric
> s-dropwizardmetrics3
> [3] https://github.com/joshelser/dropwizard-hadoop-metrics2
>
>
> Nick Dimiduk wrote:
>
>> 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<en...@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
>>>
>>>
>>

Re: Coprocessor metrics

[Gary Helmling <gh...@gmail.com>]

>
>
> My current feeling is that external API should never include
> classes/interfaces which you don't "own". Re-building the API that
> already exists is pedantic, but I think it's a really good way to pay
> down the maintenance debt (whenever the next metrics library "hotness"
> takes off).
>
>
+1 to this.  I'd be very hesitant to tie ourselves too strongly to a
specific implementation, even if it is just copying an interface.

For coprocessors specifically, I think we can start with a limited API
exposing common metric types and evolve it from there.  But starting simple
seems key.

So #2 seems like the right approach to me.

Re: Coprocessor metrics

[Enis Söztutar <en...@gmail.com>]

Thanks everyone, this is really helpful. If we can leverage the work
already Josh/Nick did in Avatica in HBase that will be really good.

Seems that the consensus is to follow #2 approach, and pay the price at
replicating the API layer in HBase for the convenience of coprocessors and
not to tie ourselves with a third party API + implementation.

However, even if we do an avatica release, HBase depending on metrics API
in Avatica is the same thing as HBase depending on dropwizard directly
since HBase does not "control" the Avatica API either. At this point
blindly forking the code inside HBase seems like the way to go (possibly in
it's own module).

Let me poke around, and fork the code if possible inside HBase. I'll send
reviews your way.

Enis

On Mon, Nov 14, 2016 at 7:58 AM, Josh Elser <el...@apache.org> wrote:

> Yep -- see avatica-metrics[1], avatica-dropwizard-metrics3[2], and my
> dropwizard-hadoop-metrics2[3] project for what Nick is referring to.
>
> What I ended up doing in Calcite/Avatica was a step beyond your #3, Enis.
> Instead of choosing a subset of some standard metrics library to expose, I
> "re-built" the actual API that I wanted to expose. At the end of the day,
> the API I "built" was nearly 100% what dropwizard metrics' API was. I like
> the dropwizard-metrics API; however, we wanted to avoid the strong coupling
> to a single metrics implementation.
>
> My current feeling is that external API should never include
> classes/interfaces which you don't "own". Re-building the API that already
> exists is pedantic, but I think it's a really good way to pay down the
> maintenance debt (whenever the next metrics library "hotness" takes off).
>
> If it's amenable to you, Enis, I'm happy to work with you to do whatever
> decoupling of this metrics abstraction away from the "core" of Avatica
> (e.g. presently, a new update of the library would also require a full
> release of Avatica which is no-good for HBase). I think a lot of the
> lifting I've done already would be reusable by you and help make a better
> product at the end of the day.
>
> - Josh
>
> [1] https://github.com/apache/calcite/tree/master/avatica/metrics
> [2] https://github.com/apache/calcite/tree/master/avatica/metric
> s-dropwizardmetrics3
> [3] https://github.com/joshelser/dropwizard-hadoop-metrics2
>
>
> Nick Dimiduk wrote:
>
>> 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<en...@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
>>>
>>>
>>

Re: Coprocessor metrics

[Josh Elser <el...@apache.org>]

Yep -- see avatica-metrics[1], avatica-dropwizard-metrics3[2], and my 
dropwizard-hadoop-metrics2[3] project for what Nick is referring to.

What I ended up doing in Calcite/Avatica was a step beyond your #3, 
Enis. Instead of choosing a subset of some standard metrics library to 
expose, I "re-built" the actual API that I wanted to expose. At the end 
of the day, the API I "built" was nearly 100% what dropwizard metrics' 
API was. I like the dropwizard-metrics API; however, we wanted to avoid 
the strong coupling to a single metrics implementation.

My current feeling is that external API should never include 
classes/interfaces which you don't "own". Re-building the API that 
already exists is pedantic, but I think it's a really good way to pay 
down the maintenance debt (whenever the next metrics library "hotness" 
takes off).

If it's amenable to you, Enis, I'm happy to work with you to do whatever 
decoupling of this metrics abstraction away from the "core" of Avatica 
(e.g. presently, a new update of the library would also require a full 
release of Avatica which is no-good for HBase). I think a lot of the 
lifting I've done already would be reusable by you and help make a 
better product at the end of the day.

- Josh

[1] https://github.com/apache/calcite/tree/master/avatica/metrics
[2] 
https://github.com/apache/calcite/tree/master/avatica/metrics-dropwizardmetrics3
[3] https://github.com/joshelser/dropwizard-hadoop-metrics2

Nick Dimiduk wrote:
> 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<en...@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
>>
>

Re: Coprocessor metrics

[Josh Elser <el...@apache.org>]

Yep -- see avatica-metrics[1], avatica-dropwizard-metrics3[2], and my 
dropwizard-hadoop-metrics2[3] project for what Nick is referring to.

What I ended up doing in Calcite/Avatica was a step beyond your #3, 
Enis. Instead of choosing a subset of some standard metrics library to 
expose, I "re-built" the actual API that I wanted to expose. At the end 
of the day, the API I "built" was nearly 100% what dropwizard metrics' 
API was. I like the dropwizard-metrics API; however, we wanted to avoid 
the strong coupling to a single metrics implementation.

My current feeling is that external API should never include 
classes/interfaces which you don't "own". Re-building the API that 
already exists is pedantic, but I think it's a really good way to pay 
down the maintenance debt (whenever the next metrics library "hotness" 
takes off).

If it's amenable to you, Enis, I'm happy to work with you to do whatever 
decoupling of this metrics abstraction away from the "core" of Avatica 
(e.g. presently, a new update of the library would also require a full 
release of Avatica which is no-good for HBase). I think a lot of the 
lifting I've done already would be reusable by you and help make a 
better product at the end of the day.

- Josh

[1] https://github.com/apache/calcite/tree/master/avatica/metrics
[2] 
https://github.com/apache/calcite/tree/master/avatica/metrics-dropwizardmetrics3
[3] https://github.com/joshelser/dropwizard-hadoop-metrics2

Nick Dimiduk wrote:
> 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<en...@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
>>
>

Re: Coprocessor metrics

[Nick Dimiduk <nd...@gmail.com>]

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 <en...@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
>

Re: Coprocessor metrics

[Nick Dimiduk <nd...@gmail.com>]

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 <en...@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
>