I see - we are mainly interested in some CSV reporter fixes that went in (
https://github.com/codahale/metrics/pull/225). Is HEAD stable? If not, is
there a specific revision in 3.0.0 after that fix that you would recommend
as being stable for production use?
I don't mean roadmap, more something like your ambitions.
I am asking because if you are just happy with things as they are, then perhaps it is time to get interested people together and start working on a fork. This of course could only happen with your full support (no, not with just your blessing).
make JmxReporter not such a special snowflake
figure out a decent API which doesn't revolve around static MetricsRegistry instances
swap out the accordion constructors for builders
fold in Hibernate support
figure out if there's a simpler/easier naming scheme
> I don't mean roadmap, more something like your ambitions.
> I am asking because if you are just happy with things as they are, then perhaps it is time to get interested people together and start working on a fork. This of course could only happen with your full support (no, not with just your blessing).
> Kind regards,
> Erik.
> Op 09-10-12 01:11, Coda Hale schreef:
>> I don't have a roadmap, sorry.
Regarding the first 3 bullets: that is ambitious. I had similar challenges for my Sentries library. I tried to come up with something better as well, but in the end I copied your approach almost exactly.
What I did do differently was hide the naming scheme. Every sentry (the metric equivalent in Sentries) has an 'owner' class, a resource name and a type-name (e.g. "rate-limiter"). The three together uniquely name a sentry and also make up the bean name for JMX.
> For 3.0.0, I'd like to accomplish the following:
> * make JmxReporter not such a special snowflake
> * figure out a decent API which doesn't revolve around static
> MetricsRegistry instances
> * swap out the accordion constructors for builders
> * fold in Hibernate support
> * figure out if there's a simpler/easier naming scheme
Sorry to resurrect a fairly old topic, but I have a a couple questions about the timing of the 3.0 release.
I started work today on a SLF4J report to report metrics values through the SLF4J framework, similar to how the ConsoleReporter and CsvReporter classes work, but I need to use SLF4J calls (instead of just dumping to a PrintStream) for this project I'm working on as part of a log and health aggregation across instances. I think generally this would also be useful as an option for reporting, since the slf4j framework is pretty widely deployed and people might not want to always dump all the metric data to the raw console, so I'm willing to open a pull request if there's interest when I'm done.
The problem is that the API and public method names are currently incompatible between the last "stable" release of 2.2.0, and the current 3.0.0-SNAPSHOT code on the master branch. Is the 3.0 release far enough out and/or too unstable to warrant porting the reporter back to the 2.x code as well?
On Thursday, October 11, 2012 3:27:17 PM UTC-4, Coda Hale wrote:
> For 3.0.0, I'd like to accomplish the following:
> - make JmxReporter not such a special snowflake > - figure out a decent API which doesn't revolve around static > MetricsRegistry instances > - swap out the accordion constructors for builders > - fold in Hibernate support > - figure out if there's a simpler/easier naming scheme
> On Oct 11, 2012, at 11:09 AM, Erik van Oosten <e.van...@grons.nl<javascript:>> > wrote:
> I don't mean roadmap, more something like your ambitions.
> I am asking because if you are just happy with things as they are, then > perhaps it is time to get interested people together and start working on a > fork. This of course could only happen with your full support (no, not with > just your blessing).
First of all, I would like to thank all the contributors that created such a great metrics library.
It would be great to keep the momentum going on this library and I am sure there are good amount of people on this mailing list that are ready to help / contribute. I noticed that there have not been much activity in the code base in the last 3 month or so. Would be great to know what can we do as the community to help merge the outstanding pull requests / contribute to open issues etc.
On Tuesday, January 29, 2013 5:25:45 PM UTC-5, Andrew McDaniel wrote:
> Hi,
> Sorry to resurrect a fairly old topic, but I have a a couple questions > about the timing of the 3.0 release.
> I started work today on a SLF4J report to report metrics values through > the SLF4J framework, similar to how the ConsoleReporter and CsvReporter > classes work, but I need to use SLF4J calls (instead of just dumping to a > PrintStream) for this project I'm working on as part of a log and health > aggregation across instances. I think generally this would also be useful > as an option for reporting, since the slf4j framework is pretty widely > deployed and people might not want to always dump all the metric data to > the raw console, so I'm willing to open a pull request if there's interest > when I'm done.
> The problem is that the API and public method names are currently > incompatible between the last "stable" release of 2.2.0, and the current > 3.0.0-SNAPSHOT code on the master branch. Is the 3.0 release far enough out > and/or too unstable to warrant porting the reporter back to the 2.x code as > well?
> On Thursday, October 11, 2012 3:27:17 PM UTC-4, Coda Hale wrote:
>> For 3.0.0, I'd like to accomplish the following:
>> - make JmxReporter not such a special snowflake >> - figure out a decent API which doesn't revolve around static >> MetricsRegistry instances >> - swap out the accordion constructors for builders >> - fold in Hibernate support >> - figure out if there's a simpler/easier naming scheme
>> On Oct 11, 2012, at 11:09 AM, Erik van Oosten <e.van...@grons.nl> wrote:
>> I don't mean roadmap, more something like your ambitions.
>> I am asking because if you are just happy with things as they are, then >> perhaps it is time to get interested people together and start working on a >> fork. This of course could only happen with your full support (no, not with >> just your blessing).
On Sunday, March 3, 2013 2:20:57 PM UTC-5, Alex Rovner wrote:
> First of all, I would like to thank all the contributors that created such > a great metrics library.
> It would be great to keep the momentum going on this library and I am sure > there are good amount of people on this mailing list that are ready to help > / contribute. I noticed that there have not been much activity in the code > base in the last 3 month or so. Would be great to know what can we do as > the community to help merge the outstanding pull requests / contribute to > open issues etc.
> Thanks > Alex
> On Tuesday, January 29, 2013 5:25:45 PM UTC-5, Andrew McDaniel wrote:
>> Hi,
>> Sorry to resurrect a fairly old topic, but I have a a couple questions >> about the timing of the 3.0 release.
>> I started work today on a SLF4J report to report metrics values through >> the SLF4J framework, similar to how the ConsoleReporter and CsvReporter >> classes work, but I need to use SLF4J calls (instead of just dumping to a >> PrintStream) for this project I'm working on as part of a log and health >> aggregation across instances. I think generally this would also be useful >> as an option for reporting, since the slf4j framework is pretty widely >> deployed and people might not want to always dump all the metric data to >> the raw console, so I'm willing to open a pull request if there's interest >> when I'm done.
>> The problem is that the API and public method names are currently >> incompatible between the last "stable" release of 2.2.0, and the current >> 3.0.0-SNAPSHOT code on the master branch. Is the 3.0 release far enough out >> and/or too unstable to warrant porting the reporter back to the 2.x code as >> well?
>> On Thursday, October 11, 2012 3:27:17 PM UTC-4, Coda Hale wrote:
>>> For 3.0.0, I'd like to accomplish the following:
>>> - make JmxReporter not such a special snowflake >>> - figure out a decent API which doesn't revolve around static >>> MetricsRegistry instances >>> - swap out the accordion constructors for builders >>> - fold in Hibernate support >>> - figure out if there's a simpler/easier naming scheme
>>> On Oct 11, 2012, at 11:09 AM, Erik van Oosten <e.van...@grons.nl> wrote:
>>> I don't mean roadmap, more something like your ambitions.
>>> I am asking because if you are just happy with things as they are, then >>> perhaps it is time to get interested people together and start working on a >>> fork. This of course could only happen with your full support (no, not with >>> just your blessing).
> Go find where Coda is hiding and see if he's still alive. Pull requests have been piling up like an elderly person's mail and newspapers. :)
> On Sunday, March 3, 2013 2:20:57 PM UTC-5, Alex Rovner wrote:
>> First of all, I would like to thank all the contributors that created such a great metrics library.
>> It would be great to keep the momentum going on this library and I am sure there are good amount of people on this mailing list that are ready to help / contribute. I noticed that there have not been much activity in the code base in the last 3 month or so. Would be great to know what can we do as the community to help merge the outstanding pull requests / contribute to open issues etc.
>> Thanks
>> Alex
>> On Tuesday, January 29, 2013 5:25:45 PM UTC-5, Andrew McDaniel wrote:
>>> Hi,
>>> Sorry to resurrect a fairly old topic, but I have a a couple questions about the timing of the 3.0 release.
>>> I started work today on a SLF4J report to report metrics values through the SLF4J framework, similar to how the ConsoleReporter and CsvReporter classes work, but I need to use SLF4J calls (instead of just dumping to a PrintStream) for this project I'm working on as part of a log and health aggregation across instances. I think generally this would also be useful as an option for reporting, since the slf4j framework is pretty widely deployed and people might not want to always dump all the metric data to the raw console, so I'm willing to open a pull request if there's interest when I'm done.
>>> The problem is that the API and public method names are currently incompatible between the last "stable" release of 2.2.0, and the current 3.0.0-SNAPSHOT code on the master branch. Is the 3.0 release far enough out and/or too unstable to warrant porting the reporter back to the 2.x code as well?
>>> On Thursday, October 11, 2012 3:27:17 PM UTC-4, Coda Hale wrote:
>>>> For 3.0.0, I'd like to accomplish the following:
>>>> make JmxReporter not such a special snowflake
>>>> figure out a decent API which doesn't revolve around static MetricsRegistry instances
>>>> swap out the accordion constructors for builders
>>>> fold in Hibernate support
>>>> figure out if there's a simpler/easier naming scheme
>>>> On Oct 11, 2012, at 11:09 AM, Erik van Oosten <e.van...@grons.nl> wrote:
>>>>> I don't mean roadmap, more something like your ambitions.
>>>>> I am asking because if you are just happy with things as they are, then perhaps it is time to get interested people together and start working on a fork. This of course could only happen with your full support (no, not with just your blessing).
>>>>> Kind regards,
>>>>> Erik.
>>>>> Op 09-10-12 01:11, Coda Hale schreef:
>>>>>> I don't have a roadmap, sorry.
Well, careful what you wish for. Metrics now has a lot less open issues.
The good news: I've had some time lately to play with all the various ideas I've had for simplifying the hell out of Metrics. Much of the 2.x line is scar tissue, where I did something weird in order to get something down the line to not suck (looking at you, Ganglia) or merged something without really looking at it, and the metrics-3 branch represents a substantially simpler way of doing things. It requires some compromises, but I think they're worth it.
The bad news: it's definitely not ready yet. Besides still needing to port over and unfuck Ganglia, Graphite, JDBI, Jetty, JVM, Log4j, Logback, and Servlet support, there are still some big issues I need to solve. These aren't really the sorts of problems which do best when crowdsourced, and right now I think it's a better use of my time to jump in and hack this stuff out rather than try to figure out who wants to do what, etc. Which leads me to…
The worst news: holy crap is my OSS governance bad. As much as I'd like to just work on Metrics all day (I don't, actually), it's not what I get paid to do. It's a hobby, and as a hobby it cuts into both my professional time and my personal time. This is one of the reasons I'm cutting modules left and right — if I don't directly care about something, it's gonna be way down in the "never get done" section of my to do list. I'm not sure what to do about this; punting Metrics into something like Apache just seems like a great way to kill it, but having it be my -20% project doesn't seem right either. I'm open to suggestions here.
And now, considering I have to wake up in 7 hours, I'm going to bed.
> Go find where Coda is hiding and see if he's still alive. Pull requests have been piling up like an elderly person's mail and newspapers. :)
> On Sunday, March 3, 2013 2:20:57 PM UTC-5, Alex Rovner wrote:
> First of all, I would like to thank all the contributors that created such a great metrics library.
> It would be great to keep the momentum going on this library and I am sure there are good amount of people on this mailing list that are ready to help / contribute. I noticed that there have not been much activity in the code base in the last 3 month or so. Would be great to know what can we do as the community to help merge the outstanding pull requests / contribute to open issues etc.
> Thanks
> Alex
> On Tuesday, January 29, 2013 5:25:45 PM UTC-5, Andrew McDaniel wrote:
> Hi,
> Sorry to resurrect a fairly old topic, but I have a a couple questions about the timing of the 3.0 release.
> I started work today on a SLF4J report to report metrics values through the SLF4J framework, similar to how the ConsoleReporter and CsvReporter classes work, but I need to use SLF4J calls (instead of just dumping to a PrintStream) for this project I'm working on as part of a log and health aggregation across instances. I think generally this would also be useful as an option for reporting, since the slf4j framework is pretty widely deployed and people might not want to always dump all the metric data to the raw console, so I'm willing to open a pull request if there's interest when I'm done.
> The problem is that the API and public method names are currently incompatible between the last "stable" release of 2.2.0, and the current 3.0.0-SNAPSHOT code on the master branch. Is the 3.0 release far enough out and/or too unstable to warrant porting the reporter back to the 2.x code as well?
> On Thursday, October 11, 2012 3:27:17 PM UTC-4, Coda Hale wrote:
> For 3.0.0, I'd like to accomplish the following:
> make JmxReporter not such a special snowflake
> figure out a decent API which doesn't revolve around static MetricsRegistry instances
> swap out the accordion constructors for builders
> fold in Hibernate support
> figure out if there's a simpler/easier naming scheme
> On Oct 11, 2012, at 11:09 AM, Erik van Oosten <e.van...@grons.nl> wrote:
>> I don't mean roadmap, more something like your ambitions.
>> I am asking because if you are just happy with things as they are, then perhaps it is time to get interested people together and start working on a fork. This of course could only happen with your full support (no, not with just your blessing).
>> Kind regards,
>> Erik.
>> Op 09-10-12 01:11, Coda Hale schreef:
>>> I don't have a roadmap, sorry.
> -- > You received this message because you are subscribed to the Google Groups "metrics-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to metrics-user+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
On Mon, Mar 11, 2013 at 6:23 AM, Coda Hale <coda.h...@gmail.com> wrote:
> The worst news: holy crap is my OSS governance bad. As much as I'd like to
> just work on Metrics all day (I don't, actually), it's not what I get paid
> to do. It's a hobby, and as a hobby it cuts into both my professional time
> and my personal time. This is one of the reasons I'm cutting modules left
> and right — if I don't directly care about something, it's gonna be way down
> in the "never get done" section of my to do list. I'm not sure what to do
> about this; punting Metrics into something like Apache just seems like a
> great way to kill it, but having it be my -20% project doesn't seem right
> either. I'm open to suggestions here.
Some random suggestions from the sidelines (not that I've been much
better in the past myself anyway! ;) --
* if there's a separate Foo integration library that can be extracted
into its own separate release or project, do it. Keep the core small
and tightly focussed on the stuff you care about (and can use and
test). So for example, break out metrics-ganglia into a separate
project with separate maintainership and a potentially slower release
schedule. Define good APIs for it to integrate against.
* If there's still a chunk of code you don't care about, and it's
logically separable but hard to separate at the code level, it may be
worth creating an API to allow it to be separated. (plugin APIs are a
good example of this)
* don't accept pull requests if they don't have good tests, so that
you can have good confidence that a green unit test run means
something is releasable.
* I'd actually think it'd be very cool to have an "Apache Metrics". ;)
but yeah, it's hard to keep up community momentum with a transfer to
the ASF unless you have a lot of time to get through incubation and a
strong community to start with...
You may already be doing most of these, I haven't been following the
project for long. Thanks for Metrics btw! It's proving to be a great
means of porting my metrics-driven habits to a new company with no
existing metrics infrastructure -- great to not have to reinvent such
a massive wheel...
7 hours sounds very nice from there I sit. It's all relative. :)
Re Metrics and ASF - it may actually do well. I suspect it would have an easy time attracting contributors and committers because it's so popular already and not some niche thing. This means it could run through the Incubator. This also means those modules can be on top of somebody else's todo list instead of being rejected for the completely realistic fear of being at the bottom of Coda's todo list.
On Monday, March 11, 2013 6:21:11 AM UTC-4, Justin Mason wrote:
> On Mon, Mar 11, 2013 at 6:23 AM, Coda Hale <coda...@gmail.com<javascript:>> > wrote: > > The worst news: holy crap is my OSS governance bad. As much as I'd like > to > > just work on Metrics all day (I don't, actually), it's not what I get > paid > > to do. It's a hobby, and as a hobby it cuts into both my professional > time > > and my personal time. This is one of the reasons I'm cutting modules > left > > and right — if I don't directly care about something, it's gonna be way > down > > in the "never get done" section of my to do list. I'm not sure what to > do > > about this; punting Metrics into something like Apache just seems like a > > great way to kill it, but having it be my -20% project doesn't seem > right > > either. I'm open to suggestions here.
> Some random suggestions from the sidelines (not that I've been much > better in the past myself anyway! ;) --
> * if there's a separate Foo integration library that can be extracted > into its own separate release or project, do it. Keep the core small > and tightly focussed on the stuff you care about (and can use and > test). So for example, break out metrics-ganglia into a separate > project with separate maintainership and a potentially slower release > schedule. Define good APIs for it to integrate against.
> * If there's still a chunk of code you don't care about, and it's > logically separable but hard to separate at the code level, it may be > worth creating an API to allow it to be separated. (plugin APIs are a > good example of this)
> * don't accept pull requests if they don't have good tests, so that > you can have good confidence that a green unit test run means > something is releasable.
> * I'd actually think it'd be very cool to have an "Apache Metrics". ;) > but yeah, it's hard to keep up community momentum with a transfer to > the ASF unless you have a lot of time to get through incubation and a > strong community to start with...
> You may already be doing most of these, I haven't been following the > project for long. Thanks for Metrics btw! It's proving to be a great > means of porting my metrics-driven habits to a new company with no > existing metrics infrastructure -- great to not have to reinvent such > a massive wheel...
On Mon, Mar 11, 2013 at 7:23 AM, Coda Hale <coda.h...@gmail.com> wrote:
...
> The bad news: it's definitely not ready yet. Besides still needing to port
> over and unfuck Ganglia, Graphite, JDBI, Jetty, JVM, Log4j, Logback, and
> Servlet support, there are still some big issues I need to solve. These
> aren't really the sorts of problems which do best when crowdsourced, and
> right now I think it's a better use of my time to jump in and hack this
> stuff out rather than try to figure out who wants to do what, etc.
...
> in the "never get done" section of my to do list. I'm not sure what to do
> about this; punting Metrics into something like Apache just seems like a
> great way to kill it, but having it be my -20% project doesn't seem right
> either. I'm open to suggestions here.
I prefer a slow evolving Coda cultivated Github project over an Apache
project any day.
The code is straightforward, generally well written and very easy to
fork and patch for specific needs or use cases that doesn't fit the
Metrics world view. I've run custom, patched, versions in production
from time to time and don't find it all to troublesome.
For the short term, based on what Coda writes regarding the metrics-3
branch, my immediate thought is whether Coda could define the
"framework" and delegate individual components such as Ganglia,
Graphite etc to those willing to help and work with them through PRs.
Further down the road, after version 3, the "obvious" improvement to
me would be if a few people besides Coda had commit access which at
least would allow some higher merge throughput on PRs.
One of the options is to let someone else maintain the 2.x branch. This would ensure that there is still some room for small improvements while you are improving Metrics more fundamentally.
>Well, careful what you wish for. Metrics now has a lot less open issues.
>The good news: I've had some time lately to play with all the various ideas I've had for simplifying the hell out of Metrics. Much of the 2.x line is scar tissue, where I did something weird in order to get something down the line to not suck (looking at you, Ganglia) or merged something without really looking at it, and the metrics-3 branch represents a substantially simpler way of doing things. It requires some compromises, but I think they're worth it.
>The bad news: it's definitely not ready yet. Besides still needing to port over and unfuck Ganglia, Graphite, JDBI, Jetty, JVM, Log4j, Logback, and Servlet support, there are still some big issues I need to solve. These aren't really the sorts of problems which do best when crowdsourced, and right now I think it's a better use of my time to jump in and hack this stuff out rather than try to figure out who wants to do what, etc. Which leads me to…
>The worst news: holy crap is my OSS governance bad. As much as I'd like to just work on Metrics all day (I don't, actually), it's not what I get paid to do. It's a hobby, and as a hobby it cuts into both my professional time and my personal time. This is one of the reasons I'm cutting modules left and right — if I don't directly care about something, it's gonna be way down in the "never get done" section of my to do list. I'm not sure what to do about this; punting Metrics into something like Apache just seems like a great way to kill it, but having it be my -20% project doesn't seem right either. I'm open to suggestions here.
>And now, considering I have to wake up in 7 hours, I'm going to bed.
>On Mar 7, 2013, at 7:31 AM, Andrew McDaniel <awmcdan...@gmail.com> wrote:
>Go find where Coda is hiding and see if he's still alive. Pull requests have been piling up like an elderly person's mail and newspapers. :)
>On Sunday, March 3, 2013 2:20:57 PM UTC-5, Alex Rovner wrote:
>First of all, I would like to thank all the contributors that created such a great metrics library.
>It would be great to keep the momentum going on this library and I am sure there are good amount of people on this mailing list that are ready to help / contribute. I noticed that there have not been much activity in the code base in the last 3 month or so. Would be great to know what can we do as the community to help merge the outstanding pull requests / contribute to open issues etc.
>Thanks
>Alex
>On Tuesday, January 29, 2013 5:25:45 PM UTC-5, Andrew McDaniel wrote:
>Hi,
>Sorry to resurrect a fairly old topic, but I have a a couple questions about the timing of the 3.0 release.
>I started work today on a SLF4J report to report metrics values through the SLF4J framework, similar to how the ConsoleReporter and CsvReporter classes work, but I need to use SLF4J calls (instead of just dumping to a PrintStream) for this project I'm working on as part of a log and health aggregation across instances. I think generally this would also be useful as an option for reporting, since the slf4j framework is pretty widely deployed and people might not want to always dump all the metric data to the raw console, so I'm willing to open a pull request if there's interest when I'm done.
>The problem is that the API and public method names are currently incompatible between the last "stable" release of 2.2.0, and the current 3.0.0-SNAPSHOT code on the master branch. Is the 3.0 release far enough out and/or too unstable to warrant porting the reporter back to the 2.x code as well?
>On Thursday, October 11, 2012 3:27:17 PM UTC-4, Coda Hale wrote:
>For 3.0.0, I'd like to accomplish the following:
>make JmxReporter not such a special snowflakefigure out a decent API which doesn't revolve around static MetricsRegistry instancesswap out the accordion constructors for buildersfold in Hibernate supportfigure out if there's a simpler/easier naming scheme
>On Oct 11, 2012, at 11:09 AM, Erik van Oosten <e.van...@grons.nl> wrote:
>I don't mean roadmap, more something like your ambitions.
>I am asking because if you are just happy with things as they are, then perhaps it is time to get interested people together and start working on a fork. This of course could only happen with your full support (no, not with just your blessing).
>-- >You received this message because you are subscribed to the Google Groups "metrics-user" group. >To unsubscribe from this group and stop receiving emails from it, send an email to metrics-user+unsubscribe@googlegroups.com. >For more options, visit https://groups.google.com/groups/opt_out. > >
>-- >You received this message because you are subscribed to the Google Groups "metrics-user" group. >To unsubscribe from this group and stop receiving emails from it, send an email to metrics-user+unsubscribe@googlegroups.com. >For more options, visit https://groups.google.com/groups/opt_out. > >
