skip to content

Micrometer Metrics & Export

Micrometer as the metrics facade: registries per backend, counters and gauges, timers and summaries, tags and filters, annotations, exporters, and the meters Boot registers for you. Interviewers ask about metric design, and cardinality is where most answers fail.

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

explore

questions

page 2 of 2

Explain the difference between publishPercentiles, publishPercentileHistogram, and serviceLevelObjectives on a Timer/DistributionSummary, and why it matters for aggregation across instances.

level: principalimportance: should knowfreq 40%

basics

~10 s

publishPercentiles computes percentiles inside each instance (not mergeable across instances). publishPercentileHistogram exports histogram buckets the backend aggregates to compute percentiles. serviceLevelObjectives adds explicit boundary buckets so you can measure the fraction meeting a target.

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

As a principal engineer, when would you prefer declarative @Timed/@Counted over programmatic Micrometer instrumentation, and what are the risks at scale?

level: principalimportance: nice to knowfreq 22%

basics

~20 s

Use @Timed/@Counted for quick, low-boilerplate, method-level metrics on Spring beans. Use programmatic Micrometer when you need dynamic tags, to time part of a method, or to avoid proxy limits. At scale watch tag cardinality, the AOP proxy constraints, and consistent naming.

open as a page

For a fleet of Spring Boot services — some long-lived, some serverless/ephemeral — how would you decide between Prometheus scraping and OTLP push, and what failure modes shape that choice?

level: principalimportance: nice to knowfreq 25%

basics

~10 s

Use Prometheus scraping for stable, discoverable services (free liveness via failed scrapes, monitor controls timing). Use OTLP push for ephemeral/serverless or unreachable apps. Often run both through an OpenTelemetry Collector, migrating incrementally.

open as a page

As a principal engineer, how would you design a fleet-wide tagging and MeterFilter strategy for many Spring Boot services sharing one Prometheus?

level: principalimportance: nice to knowfreq 22%

basics

~20 s

Standardize a common-tag contract (application, env, region, instance) via a shared library, enforce tag hygiene with shared MeterFilters (ignoreTags, replaceTagValues, maximumAllowableTags as a backstop), keep ids in logs/traces, and monitor active-series cardinality as an SLO. Ship it as an auto-configured starter so every service inherits it by default.

open as a page

showing 31–35 of 35