skip to content

Auto-configured Meters & MeterBinders

4 roadmaps6 questions

Boot registers meters for HTTP server and client latency with URI and status tags, JVM memory, GC and threads, CPU, connection pools and log events. Interviewers ask why the uri tag is templated rather than raw — again, cardinality.

part ofSpring Frameworkoverview, primer and where to startread it →
on this pageshow

explore

questions

6

What meters does Spring Boot auto-configure out of the box, and what is a MeterBinder?

level: juniorimportance: must knowfreq 62%

answer

  1. actuator + micrometer => free meters
  2. MeterBinder.bindTo(registry)
  3. jvm.memory / jvm.gc / jvm.threads / system.cpu / process
  4. http.server.requests Timer
  5. hikaricp + logback.events

basics

~20 s

With Actuator + Micrometer on the classpath, Boot auto-registers meters for JVM memory/GC/threads, CPU, process, HTTP requests, datasource, and logback events. A MeterBinder is a small class that binds one such set of metrics to the MeterRegistry.

solid answer

~30 s

Adding spring-boot-starter-actuator (which pulls in micrometer-core) makes Boot auto-configure a broad set of meters without any code. Core groups: jvm.memory.used/max/committed, jvm.gc.*, jvm.threads.*, system.cpu.usage and process.cpu.usage, process.uptime/start.time, http.server.requests (a Timer per endpoint), and — when present — http.client.requests, hikaricp.*/jdbc datasource pool metrics, and logback.events (log lines by level). Each group is produced by a MeterBinder — an interface with bindTo(MeterRegistry) — such as JvmMemoryMetrics, JvmGcMetrics, ProcessorMetrics, LogbackMetrics. Boot registers every MeterBinder bean it finds against the registry. You expose them at /actuator/metrics and /actuator/prometheus. So a MeterBinder is the plug-in unit that knows how to register a related family of gauges/counters/timers.

code

java · 19 lines
java
// The MeterBinder contract (Micrometer)
public interface MeterBinder {
    void bindTo(MeterRegistry registry);
}

// A built-in binder Boot registers for you:
// io.micrometer.core.instrument.binder.jvm.JvmMemoryMetrics
// io.micrometer.core.instrument.binder.system.ProcessorMetrics
// io.micrometer.core.instrument.binder.logging.LogbackMetrics

// Any MeterBinder @Bean is auto-bound to the primary MeterRegistry:
@Configuration
class MetricsConfig {
    @Bean
    MeterBinder queueSize(WorkQueue queue) {
        return registry -> Gauge.builder("app.queue.size", queue, WorkQueue::size)
                                .register(registry);
    }
}

go deeper

for a junior

Know that actuator gives free JVM/HTTP/process metrics and that MeterBinder registers a family of meters.

for a middle

Name the concrete binder classes and the meter names/types each produces.

for a senior

Explain conditional registration and how a MeterBinder bean is auto-bound to the registry.

for a principal

Frame built-ins as covering RED/USE signals and decide what custom instrumentation is still needed on top.

## The big picture Spring Boot's Actuator, combined with **Micrometer** (a vendor-neutral metrics facade, think 'SLF4J for metrics'), gives you a large catalog of production metrics for free. You add one dependency — `spring-boot-starter-actuator` — and Boot's `MetricsAutoConfiguration` / `*MetricsAutoConfiguration` classes register meters against a `MeterRegistry` bean. ### Key terms - **Meter**: a single metric. Micrometer meter types: `Counter` (monotonic count), `Gauge` (instantaneous value that can go up/down, e.g. memory used), `Timer` (count + total time + max of timed events), `DistributionSummary`, `LongTaskTimer`, `FunctionCounter`/`FunctionTimer`. - **MeterRegistry**: the collection all meters are registered into and the thing a monitoring backend reads from (e.g. `PrometheusMeterRegistry`). - **MeterBinder**: a functional-ish interface `interface MeterBinder { void bindTo(MeterRegistry registry); }`. It packages the logic to create and register a *related family* of meters. Boot auto-detects every `MeterBinder` bean in the context and calls `bindTo` on the primary registry via `MeterRegistryPostProcessor`. ### What Boot auto-registers (the built-ins) Provided by Micrometer's `io.micrometer.core.instrument.binder.*` classes, enabled by Boot auto-config: - **JVM**: `JvmMemoryMetrics` -> `jvm.memory.used/committed/max` (tagged by `area`=heap/nonheap and memory pool `id`); `JvmGcMetrics` -> `jvm.gc.pause` timer, `jvm.gc.memory.allocated/promoted`; `JvmThreadMetrics` -> `jvm.threads.live/daemon/peak/states`; `ClassLoaderMetrics` -> `jvm.classes.loaded`. - **System/Process**: `ProcessorMetrics` -> `system.cpu.usage`, `process.cpu.usage`, `system.cpu.count`, `system.load.average.1m`; `UptimeMetrics` -> `process.uptime`, `process.start.time`; `FileDescriptorMetrics` -> `process.files.open/max`. - **HTTP server**: `http.server.requests` — a `Timer` recorded per request by a Servlet `Filter`/WebFlux `WebFilter` (`ServerHttpObservationFilter` in modern Boot), tagged with `uri`, `method`, `status`, `outcome`, `exception`. - **HTTP client**: `http.client.requests` for `RestTemplate`/`RestClient`/`WebClient` instrumented by Boot. - **DataSource/pool**: `DataSourcePoolMetrics` -> `jdbc.connections.*`; if HikariCP is the pool, `hikaricp.connections.*` (active/idle/pending/timeout/usage/acquire). - **Logging**: `LogbackMetrics` -> `logback.events` counter tagged by `level` (error/warn/info/...). - **Tomcat/Jetty**: `TomcatMetrics` -> `tomcat.*` when the container manager is available. ### How to see them `management.endpoints.web.exposure.include=metrics,prometheus`. Then `GET /actuator/metrics` lists names, `GET /actuator/metrics/jvm.memory.used` drills into one, `GET /actuator/prometheus` gives the scrape format. ### Gotchas - Some binders only register when their dependency/condition is present (HikariCP metrics need HikariCP; `http.client.requests` needs an instrumented client). - Metrics are lazily/eagerly created but a Timer like `http.server.requests` only shows tag values that have actually been observed. ### When to rely on them Almost always — they cover the standard RED/USE signals (request rate/errors/duration + resource saturation) with zero code, which is exactly what you want before adding custom business metrics.

  • Which single dependency turns most of these on, and how do you view them?
    spring-boot-starter-actuator (it brings micrometer-core). View via /actuator/metrics, drill into one with /actuator/metrics/{name}, or scrape /actuator/prometheus after exposing the endpoint.
  • Are all built-in meters always registered?
    No — many are conditional. hikaricp.* needs HikariCP as the pool, http.client.requests needs an instrumented RestTemplate/WebClient, TomcatMetrics needs the Tomcat manager. JVM/process/CPU/logback ones are effectively always on.

saying these in an interview costs you the question

  • Thinking you must write code to get JVM/HTTP metrics
  • Believing http.server.requests is a Gauge or Counter rather than a Timer
  • Assuming MeterBinder is a Spring annotation rather than a Micrometer interface

context

resolving links…

open as a page

Explain the http.server.requests meter: what tags does it carry and how is it recorded?

level: middleimportance: must knowfreq 68%

basics

~20 s

http.server.requests is a Timer recorded for every HTTP request, tagged with uri, method, status and outcome so you can see request rate, error rate and latency per endpoint. It is added automatically by an Actuator filter.

open as a page

Which JVM, process and system meters does Boot expose, and how do you read jvm.memory / jvm.gc / system.cpu?

level: middleimportance: should knowfreq 48%

basics

~10 s

Boot exposes jvm.memory.used/max/committed (tagged by area and pool), jvm.gc.pause and allocation counters, jvm.threads.live/daemon/peak, plus system.cpu.usage and process.cpu.usage, process.uptime and process.start.time. They come from Micrometer JVM/System binders.

open as a page

How do the datasource/HikariCP pool metrics and logback.events meter get registered, and what do they tell you?

level: seniorimportance: should knowfreq 40%

basics

~20 s

When a DataSource bean exists Boot registers jdbc.connections.* pool metrics; if the pool is HikariCP it also exposes hikaricp.connections.active/idle/pending/max plus timing metrics. logback.events counts log lines per level via LogbackMetrics, so you can alert on error-log rate.

open as a page

The uri tag on http.client.requests is causing a metrics cardinality explosion. How do the built-in meters get their tags, and how do you control/limit cardinality across the registry?

level: principalimportance: should knowfreq 34%

basics

~20 s

Built-in meters get tags from Observation conventions (server/client). To limit cardinality, ensure client calls use URI templates (not interpolated URLs), and add a MeterFilter to deny high-cardinality tags, cap max tag values, rename, or drop whole meters registry-wide.

open as a page

How do you add your own MeterBinder or common tags alongside the auto-configured meters, and when should you prefer that over @Timed/manual meters?

level: seniorimportance: nice to knowfreq 28%

basics

~20 s

Expose a MeterBinder @Bean and Boot binds it to the registry automatically, just like the built-ins. To add tags to every meter (built-in included) register a MeterRegistryCustomizer or MeterFilter.commonTags. Prefer a MeterBinder when you're exposing the state of a long-lived resource.

open as a page