Future of metrics 4.0 and metric tags

[rconn01]

What is the planned future for metrics 4.0. Looking at the history it looks like 4.0 was developing in the master branch https://github.com/dropwizard/metrics/tree/master It looks like the default branch was recently switched to a new 4.0-development branch that branches from the latest 3.X release.

My question here is what is the plan moving forward for metrics and are there any target release dates for a 4.0 release. Is the original work that was done in the master branch now dead and the plan is to move forward with 4.0-development?

Assuming that is true since it's the default branch, what is the plan for tag support? The new MetricName was added to master which allowed metrics to have tags which I think is the number one feature currently missing from metrics. More and more data sources support tags (opentsdb, influx, prometheus, etc) and the tag support enables many features in these data sources. I would really hate for tag support not exist in the metrics lib as it would significantly limit the flexibility of capturing metrics. So I'm hoping that there is plan to add tag support back into the 4.X release and if there isn't one, how can we work to get them back in.

[arteam]

Thank you for the question and your persistence in adding support for tags!

My plan was to release Metrics 4.0 as a cleaned up, Java 8, mostly API compatible version of Metrics 3.2. After that I wanted to proceed with breaking changes like support of tags. I actually very like the idea to add the native support of tags, because I see too how many modern time-series databases are shifting in this direction (and we have questions like #1165). I believe it's a major feature of the new generation of the Metrics library and I will review/accept merge requests to add it.

I am afraid the master branch (with support for tags) is actually dead. It has a mix of bug fixes, improvements, new features, breaking changes and so on. It was the reason I started 4.0-development: to make the transition from 3.2 to 4.0 more clear for users and developers (at least the project's SCM history looks clean).

Regarding the release plan, I've released only 2 alphas for 4.0 to the Maven Central (sorry, even without release notes). I think the best strategy would be to release Metrics 4.0 (I can do that more or less with the current state of the 4.0 branch), continue backward-compatible work there (for example the work on #1161), and then create a branch for Metrics 5.0 (tag support). I will then continue making maintenance releases for the 3.2 and 4.0 branches. I think the strategy of small releases in different branches is better than making one big release with a lot of changes.

I've recently been busy with other things, but I will try to get more time to drive this project. So, the next action from my side would be to release 4.0 to the Maven Central and we can focus on adding support for tags for Metrics 5.0. Does this sound good for you?

[rconn01]

Thanks for the explanation @arteam and at a high level I think this makes sense. Curious on your thoughts around timelines. Sounds like metrics 4.0 is almost ready to release within the next few weeks, at which point we can start building out 5.0. What's the idea on timelines for getting a 5.0 release. Is it going to be a long running branch where you plan on adding many breaking features or do you plan on following the strategy of making many small releases on the 5.0 branch as well?

Also more than happy to help get tag support into an official release of metrics, I think it will be a huge benefit for many users and help open up newer use cases for users.

[lnorregaard]

Hi

What about the pull request that was submitted to master about collectd could that be included in the 4.0 branch as well?

[arteam]

I will accept a pull request to the 4.0-branch to include a collectd since it was already merged and I can't find a separately maintained alternative.

[g-fresh]

Created a pull request (#1231) for the metrics-collectd module, which was originally added by @dernasherbrezon.

[maciejp]

Hi,

Now that 4.0.0 is released what are the plans regarding support for tags? I have a use case for which tags are the only solution so if there's a way for me to help with introducing them just let me know.

[arteam]

Yes, I will consider support for tags in 5.0.0. I will need to dig up the original PR with support for tags, which was merged to the master branch, but has never been released.

[maciejp]

I guess it might be this one #839 .

Any timeframe on 5.0.0 release?

[arteam]

I believe it's #561.

Unfortunately, I don't have a timeline for 5.0.0, but right now I have time to work on metrics, so I think you can expect an alpha version in a couple of weeks.

[arteam]

Okay, I've ported @udoprog's contribution to support of tags on top of the 5.0.0 branch here: https://github.com/dropwizard/metrics/commits/metric-tags. Looks it compiles and the tests are green!

[udoprog]

It's back!

Getting this would permit us to port all additions we've done in https://github.com/spotify/semantic-metrics (ffwd reporters) and only use upstream libraries. That would be perfect!

A word of caution: it currently seems like both 4.x and 5.x will be using the same packages. This really need to change since the metrics libraries are deeply embedded as a dependency in many projects. I've opened #1248 and I hope you'll be able to take it into consideration!

[arteam]

Here is a PR #1250

[rconn01]

This is great news. Once #1250 is merged I also have a few reporters that I can contribute back that are making use of the tags.

[jared2501]

Hey guys this looks great and things are merged! Any estimates when 5.0.0 will be available on maven?

[jared2501]

Ah nevermind, I see the package has moved to: https://mvnrepository.com/artifact/io.dropwizard.metrics5/metrics-core

[db-vmw]

Glad to see 5.0 in maven repo. Any example code highlighting usage of tags in metric name?

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove the "stale" label or comment or this will be closed in 14 days.