Micrometer is a vendor-neutral application observability facade for Java that lets developers instrument code with dimensional metrics once and decide on the monitoring backend at the last minute, and it is aimed at Java teams building cloud-native and microservice applications that want observability without tying their instrumentation to a single monitoring tool.

What it is

Micrometer is an application metrics facade for the most popular monitoring tools, using the same idea that SLF4J applies to logging: application code talks to one neutral interface, and the choice of backend is deferred. It lives in the Java ecosystem and is published to Maven Central under the io.micrometer group, with micrometer-core as the central artifact. Most Micrometer artifacts work with Java 8 or later, with documented exceptions such as the micrometer-java11 module and micrometer-jetty11. The project is licensed under Apache Software License 2.0 and is sponsored by VMware.

The concrete problem it solves is instrumentation lock-in. Rather than writing metrics code against one vendor's client library and rewriting it when the monitoring backend changes, a team instruments once against dimensional metrics through a vendor-neutral interface and swaps the backend later. This matters for microservice and cloud-native architectures, where many services are deployed independently and the monitoring stack is often chosen, replaced, or run in parallel after the application code already exists. The topics attached to the project — cloud-native, java, metrics, microservices, monitoring, observability — describe exactly that setting.

Key capabilities

• Vendor-neutral dimensional metrics API, delivered primarily through the io.micrometer:micrometer-core artifact on Maven Central.
• Backend selection deferred to the last minute, so instrumentation does not have to be written against a specific monitoring tool.
• Java 8 or later support across most artifacts, with separate modules for newer runtimes such as micrometer-java11 and micrometer-jetty11.
• Snapshot builds published to repo.spring.io for every successful build on the main branch and maintenance branches, consumed as io.micrometer:micrometer-core:latest.integration.
• Milestone releases and release candidates published to Maven Central starting with the 1.15.0-M2 release, explicitly marked for testing and not for production use.
• Reference documentation maintained in the docs directory of the repository and published to https://micrometer.io.
• Sample and example applications maintained in the separate micrometer-samples repository, plus a Slack community and a published support policy.

Who uses it and how

• Java teams running microservices that need consistent metrics across many independently deployed services.
• Cloud-native platform teams that want one instrumentation layer while a monitoring backend is evaluated or migrated.
• Organizations with existing Java 8 estates, since most artifacts still target Java 8 or later even where newer modules exist for newer runtimes.
• Teams that need to test unreleased behavior, using snapshot artifacts from repo.spring.io with the latest.integration version selector.
• Contributors and integrators, who work against the reference documentation in docs, the samples repository, the CONTRIBUTING.md guide, and the support policy.

Getting started

Add the io.micrometer:micrometer-core dependency from Maven Central, or use io.micrometer:micrometer-core:latest.integration from the repo.spring.io/snapshot repository if snapshot builds are needed. Reference documentation lives at https://micrometer.io, and runnable examples live in the micrometer-samples repository.

How it compares

The project describes itself in terms of SLF4J: just as SLF4J puts a facading layer between application logging calls and the logging implementation, Micrometer puts a facading layer between application metrics calls and the monitoring system. The difference in scope is that Micrometer deals in dimensional metrics for observability rather than log statements, so the analogy is about the architectural pattern rather than about interchangeable behavior.

When to use it — and when not to

Micrometer is a facade, not a monitoring backend, so adopting it still means running or paying for the monitoring tool that actually stores and queries the metrics, and someone must operate that backend. Teams not on the JVM gain nothing from it, and the project currently carries 309 open issues alongside a large fork and star count, which is normal for a widely depended-on library but worth knowing before treating it as low-maintenance. Milestone and release candidate artifacts are published to Maven Central for testing and are explicitly not intended for production, so production users should stay on stable releases.

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

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