# Micrometer: a vendor-neutral metrics facade for Java applications

> Micrometer lets you instrument Java code with dimensional metrics and choose the monitoring backend later. This review covers what it solves, how the registry abstraction works, how to install it, and where it stops being the right tool.

**micrometer-metrics/micrometer** — An application observability facade for the most popular observability tools. Think SLF4J, but for observability.

- Repository: https://github.com/micrometer-metrics/micrometer
- Website: https://micrometer.io
- Stars: 4,906 · Forks: 1,152
- Language: Java
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/micrometer-metrics-micrometer

## The problem Micrometer solves for JVM services

Instrumentation code has a habit of outliving the tool it reports to. If you call a vendor SDK directly from your service classes, switching backends means editing every call site, and library authors who want to ship metrics face an impossible choice: depend on one vendor and exclude everyone else, or depend on none and ship nothing. Micrometer takes the SLF4J position on this. The README describes it as "an application metrics facade for the most popular monitoring tools" and frames the goal as deciding on the monitoring backend "at the last minute". You instrument against a vendor-neutral interface, and a registry implementation translates those calls into whatever the backend understands. The audience is JVM application developers and library authors. The repository layout makes that explicit: micrometer-core, micrometer-commons and micrometer-observation are the facade, while implementations/ holds the bindings, and the samples/ directory contains runnable examples for Caffeine 3, Hazelcast, Javalin, Jersey 3, jOOQ, Kotlin and Spring Framework 6.

## How the registry abstraction and dimensional metrics fit together

The unit of work is the meter. Your code creates a counter, timer, gauge or distribution summary through a registry, and the registry owns the mapping to the backend. Metrics are dimensional, meaning a single meter name carries a set of key-value tags rather than encoding each variation into a separate flat name. That distinction matters at query time: a backend that stores dimensions can aggregate across one tag while filtering on another, and a backend that only accepts flat names has to rely on the registry to flatten them. The repository separates concerns at the module level. micrometer-commons holds shared abstractions, micrometer-core provides the meters and the composite registry, micrometer-observation connects metrics to the observation API, and the version-specific modules (micrometer-java11, micrometer-java21, micrometer-jakarta9, micrometer-jetty11, micrometer-jetty12) exist because some integrations need a newer bytecode target or a specific container API. The README states plainly that artifacts work with Java 8 or later "with a few exceptions such as the micrometer-java11 module and micrometer-jetty11", so the baseline is broad but not universal.

## Adding Micrometer to a build and recording a first meter

Micrometer is published to Maven Central, and the README's own badge points at the io.micrometer:micrometer-core artifact. Add the core facade plus a registry implementation for your backend. The snippet below follows the dependency style the README uses for snapshot builds, with the version left to your dependency management:

```groovy
dependencies {
    implementation 'io.micrometer:micrometer-core'
}
```

If you want to track the main branch rather than a release, the README documents a snapshot repository and the latest.integration version:

```groovy
repositories {
    maven { url 'https://repo.spring.io/snapshot' }
}

dependencies {
    implementation 'io.micrometer:micrometer-core:latest.integration'
}
```

Snapshots are published to repo.spring.io for every successful build on main and on maintenance branches, so latest.integration moves under you. For anything you intend to ship, pin a released version instead. One caveat on versions: the README notes that from 1.15.0-M2 onward, milestone releases and release candidates are published to Maven Central, and that milestone releases "are for testing purposes and are not intended for production use". The most recent tags listed are v1.18.0-M1, v1.17.1 and v1.16.7, so a stable line is available alongside the milestone. Once the dependency resolves, you create a registry, obtain a meter from it, and record against that meter; the registry, not your service class, knows how the value reaches the backend. The samples/ directory in the repository is the place to look for a working end-to-end example, and the reference documentation lives in the docs directory and is published to micrometer.io.

## Where Micrometer is the wrong choice

The facade solves metrics, and only metrics. If your requirement is distributed tracing, Micrometer's own answer is the separate micrometer-observation module, which is a distinct abstraction with its own API surface rather than something micrometer-core gives you for free. Treating the core dependency as a tracing solution will not work. There is also a cost to the indirection itself. Every meter goes through a registry, and the registry decides what the backend can actually represent; a backend that does not support a meter type, or that flattens dimensions, will not preserve the shape of what you recorded. Debugging then moves from your application code into the registry implementation, which is a harder place to look. Finally, the Java 8 baseline is a strength for reach and a constraint for integration: if you need the java11 or jetty11 modules, you are outside the baseline the README describes, and the module list in the repository shows those targets are maintained as separate artifacts rather than folded into core.

## Micrometer compared with calling a backend SDK directly

The realistic alternative is not another facade. It is skipping the facade and using the monitoring vendor's own client library in your application code. That approach has one real advantage: the vendor SDK exposes every feature the backend offers, including options a neutral interface has no concept of, and there is no translation layer between your call and the wire format. The difference in approach is where the coupling lives. With a vendor SDK, the backend choice is baked into every class that records a metric, and a migration is a code change across the codebase. With Micrometer, the backend choice is a dependency and a registry configuration, and the instrumented code stays as it is. The trade is expressiveness for portability. If you are certain about your backend and need its specific capabilities, the SDK is the more direct route. If you expect the backend to change, or you maintain a library that other teams will deploy against unknown monitoring stacks, the facade is the point. The repository's own samples repository, micrometer-samples, exists separately from the main tree, which suggests the maintainers treat runnable examples as a first-class companion rather than something to keep inside core.

## Maintenance cadence, version policy and licence

The repository is not archived, and the last push was on 2026-09-22, one day before this writing. The release tags listed are v1.18.0-M1, v1.17.1 and v1.16.7, all dated 2026-08-20, which shows three lines being cut from the same day: a milestone for the next minor, a patch on the current minor, and a patch on the previous one. That pattern is the upgrade cost in miniature. You are expected to move along patch lines and to treat milestones as testing artifacts, and the README links to a support policy page for how long each version is maintained. The repository does not document rollback procedures, and the README does not describe a compatibility guarantee between major lines beyond the Java 8 statement. Licence-wise the project is Apache-2.0, which is a permissive licence, and the README notes sponsorship by VMware. Apache-2.0 is generally compatible with commercial distribution, but the licence text and the NOTICE file in the repository root are what govern, not this summary; if your organisation has a legal review process, that is the material to send through it.

## Conclusion

Adopt Micrometer if you write Java services and want instrumentation that survives a change of monitoring backend, and start by adding io.micrometer:micrometer-core plus one registry implementation to a single service. Do not adopt it if you need traces rather than metrics, or if you are not on the JVM. Before rolling it out, verify which registry artifacts exist for your backend, confirm the Java version your modules require (micrometer-java11 and micrometer-jetty11 are exceptions to the Java 8 baseline), and check the support policy page for the maintenance window of the version you pick.

## FAQ

### What Java version does Micrometer require?

The README states that Micrometer artifacts work with Java 8 or later, with a few exceptions such as the micrometer-java11 module and micrometer-jetty11.

### Where is Micrometer published, and which artifact do I add?

The README's Maven Central badge points at io.micrometer:micrometer-core, and the snapshot instructions use the same group and artifact against the repo.spring.io snapshot repository.

### Are Micrometer milestone releases safe for production?

No. The README states that milestone releases and release candidates are published to Maven Central starting with 1.15.0-M2, and that milestone releases are for testing purposes and are not intended for production use.

### Where can I find working Micrometer example applications?

The README points to the separate micrometer-samples repository, and the main repository also contains a samples/ directory with modules for Caffeine 3, Hazelcast, Javalin, Jersey 3, jOOQ, Kotlin and Spring Framework 6.

## Sources

- [License: Apache-2.0](https://github.com/micrometer-metrics/micrometer/blob/main/LICENSE)
- [micrometer-metrics/micrometer on GitHub](https://github.com/micrometer-metrics/micrometer)
- [Project website](https://micrometer.io)
- [README](https://github.com/micrometer-metrics/micrometer/blob/main/README.md)
- [Releases](https://github.com/micrometer-metrics/micrometer/releases)

---

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