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 pageshowhide
explore
- MeterRegistry & Registry-per-Backend5 questions
- Counter & Gauge4 questions
- Timer & DistributionSummary5 questions
- Tags, Common Tags & Meter Filters5 questions
- @Timed & @Counted5 questions
- Export to Prometheus & OTLP5 questions
- Auto-configured Meters & MeterBinders6 questions
questions
page 2 of 2Explain the difference between publishPercentiles, publishPercentileHistogram, and serviceLevelObjectives on a Timer/DistributionSummary, and why it matters for aggregation across instances.
basics
~10 spublishPercentiles 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.
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?
basics
~20 sExpose 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.
As a principal engineer, when would you prefer declarative @Timed/@Counted over programmatic Micrometer instrumentation, and what are the risks at scale?
basics
~20 sUse @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.
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?
basics
~10 sUse 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.
As a principal engineer, how would you design a fleet-wide tagging and MeterFilter strategy for many Spring Boot services sharing one Prometheus?
basics
~20 sStandardize 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.
showing 31–35 of 35