# dropwizard/metrics: JVM and application metrics for Java services

> dropwizard/metrics is an Apache-2.0 Java library for capturing JVM and application-level metrics. The 4.2.x line is the branch the README marks as maintained, and 5.0.x is paused pending a breaking API.

**dropwizard/metrics** — Capturing JVM- and application-level metrics. So you know what's going on.

- Repository: https://github.com/dropwizard/metrics
- Website: https://metrics.dropwizard.io
- Stars: 7,845 · Forks: 1,794
- Language: Java
- License: Apache-2.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/dropwizard-metrics

## What dropwizard/metrics measures in a Java process

The README describes the project in one line: capturing JVM- and application-level metrics. That covers two audiences. The first is a Java service team that needs to see request rates, error counts, queue depths and latency percentiles without bolting a vendor agent onto the process. The second is anyone maintaining a JVM that has to be observed from outside, where heap, garbage collection and thread counts matter as much as business events. The library is a set of Java modules rather than a running server. metrics-core holds the metric types and the registry; the remaining top-level directories are integrations. metrics-jvm, metrics-jmx, metrics-graphite, metrics-collectd, metrics-servlet, metrics-servlets, metrics-healthchecks and a long list of framework adapters (Jetty, Jersey, Logback, Ehcache, JDBI, HttpClient and others) sit alongside it. That layout tells you the intended usage: you add the core, register metrics in your code, and pick reporters that match your infrastructure.

## How the registry, metric types and reporters fit together

The architecture visible from the repository is a registry plus reporters. Application code creates metrics and registers them under a name in a MetricRegistry. Metric types are the classic four: counters for incrementing values, gauges for values read at collection time, meters for rates, and histograms and timers for distributions and duration, with timers built on histograms plus meters. Reporters then read the registry and push or expose the values. The module list is the evidence for how many output paths exist: metrics-jmx exposes values through JMX, metrics-servlet and metrics-servlets expose them over HTTP, metrics-graphite and metrics-collectd send them to those backends, and metrics-json serializes them. Because reporters are separate modules, the library does not decide where your metrics go. That is a deliberate split and also the reason dependency selection matters more than it first appears: the core gives you the instruments, and nothing is reported until you add and start a reporter. The README does not describe the internal scheduling of reporters or the registry's concurrency model, so treat those as things to read in the Javadoc rather than assume.

## Getting the library: Maven Central, the wrapper and the docs site

The README does not print install steps. What it gives is a pointer to the documentation at metrics.dropwizard.io, a Maven Central badge for the metrics-core artifact, and the top-level repository entries. From those, the distribution channel is Maven Central under the io.dropwizard.metrics group, and the artifact the badge names is metrics-core. The README does not print a dependency snippet, so there is no block to copy here; the group and artifact names above are the ones the badge and the repository layout use. For building the library itself, the top-level entries include mvnw and mvnw.cmd, so the repository is built with the Maven wrapper rather than a system Maven install. The README does not document the wrapper invocation, so check the repository's own build files for the exact command. The version table in the README is the guide to which branch is maintained before you pick a version to resolve. Once the core artifact is on your classpath, the module directories tell you what else exists: metrics-jmx for JMX, metrics-servlet and metrics-servlets for HTTP, metrics-graphite and metrics-collectd for those backends, and metrics-json for serialization. Add only the reporter modules whose output you actually need.

## A first metric and where it goes

The README does not include a usage example, so the smallest real use has to be inferred from the module layout rather than copied. The core module is named metrics-core and the registry type the library is built around is MetricRegistry, which is the name the project's own documentation and Javadoc use. A first metric is a counter on an event you already care about, such as failed logins or processed jobs: you create a registry, ask it for a counter by name, and increment it. The registry returns the same counter for the same name, so callers do not need to thread the object through their code. On its own that counter is invisible, because nothing is reported until a reporter reads the registry. The repository offers several. metrics-jmx exposes the registry through JMX, which means you can inspect the value in a JMX console without writing an HTTP endpoint. metrics-servlet and metrics-servlets expose metrics over HTTP, and metrics-graphite or metrics-collectd push them to those backends. The practical rule from the module layout is that you add the reporter module for your chosen output and start it against the same registry. The README does not show a reporter configuration snippet, so the exact constructor arguments and scheduling options belong to the Javadoc for each reporter module, not to this page.

## The 5.x pause and the tag problem

The most important limitation is stated plainly in the README's version table. The 4.2.x branch is marked maintained, and 5.0.x is marked on pause. The future development section explains why: new not-backward-compatible features, with support for tags given as the example, will be implemented in a 5.x.x release, and that release will have new Maven coordinates, a new package name and a backwards-incompatible API. Tags are the dimensional labels that modern metrics backends use to slice a metric by endpoint, tenant or status code. Until 5.x ships, the 4.2.x line does not offer that model, and the README does not describe a migration path or a compatibility shim between the two lines. Anyone choosing this library today is therefore choosing the 4.2.x API and accepting that the tagged API, when it arrives, will require a package rename and coordinate change. The README also lists every branch before 4.2.x as unmaintained, so old tutorials that target 3.x or 4.1.x should not be treated as current guidance.

## When a different metrics approach fits better

The clearest alternative in the JVM space is Micrometer, which is built around dimensional metrics and a registry abstraction that maps to multiple backends. The difference in approach is structural rather than cosmetic. dropwizard/metrics centers on a MetricRegistry of named metrics and separate reporter modules, and the README says tag support is deferred to a 5.x release with a breaking API. Micrometer assumes tags from the start and treats the backend as a pluggable registry. If your dashboards depend on querying by label, that distinction decides the choice before any other consideration. The trade-off runs both ways: a named-metric registry is simple to reason about, and the module list here shows deep, long-standing integrations for specific Java stacks (several Jetty generations, Jersey 2 through 4, multiple Logback lines, Ehcache, JDBI, HttpClient variants) that a newer library may not cover at the same depth. If you are already inside one of those stacks, the integration modules are the reason to stay.

## Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-28, so the project is receiving commits. The README's own status table is the more useful signal for planning: 4.2.x is marked maintained, 5.0.x is on pause, and everything from 2.2.x through 4.1.x is marked unmaintained. Recent releases include v4.2.40 and v5.0.8, both dated 2026-08-28, which shows the two lines are both being cut even while 5.x is paused. Upgrade cost inside 4.2.x is the ordinary Maven version bump. The expensive upgrade is the eventual move to 5.x, because the README states it brings new Maven coordinates, a new package name and a backwards-incompatible API; that is a source-level change across every file that imports the library. On licensing, the README states the project is published under Apache Software License 2.0, with copyright held by Coda Hale, Yammer.com (2010-2013) and the Dropwizard Team (2014-2021), and the LICENSE file is in the repository root. That is a permissive licence, but read the file for the terms rather than relying on this summary.

## Conclusion

Adopt dropwizard/metrics on the 4.2.x line if you run a Java service and want counters, gauges, meters, histograms and timers reported through JMX, servlets, Graphite or CollectD. Do not adopt it if you need tag-based dimensional metrics today; the README says tags arrive in a 5.x release with new Maven coordinates, a new package name and a backwards-incompatible API, and 5.0.x is marked on pause. Before you commit, verify which branch and version your build resolves, confirm that the reporter module you need (for example metrics-jmx or metrics-servlet) is present in your dependency set, and check the LICENSE file for the Apache-2.0 terms yourself.

## FAQ

### How do I install dropwizard/metrics in a Java project?

The README does not print install steps; it points to the documentation at metrics.dropwizard.io and shows a Maven Central badge for the metrics-core artifact. Reporter modules such as metrics-jmx or metrics-servlet are separate artifacts you add only if you need that output.

### Which version of dropwizard/metrics is maintained?

The README's version table marks 4.2.x as maintained, 5.0.x as on pause, and every branch from 2.2.x through 4.1.x as unmaintained.

### Does dropwizard/metrics support tags on metrics?

Not in the 4.2.x line. The README's future development section says tag support is planned for a 5.x.x release, which will have new Maven coordinates, a new package name and a backwards-incompatible API.

## Sources

- [Official documentation](https://metrics.dropwizard.io)
- [Official README](https://github.com/dropwizard/metrics#readme)
- [Project repository](https://github.com/dropwizard/metrics)
- [Release notes](https://github.com/dropwizard/metrics/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dropwizard-metrics