Micrometer Monitoring.

What Micrometer is

Micrometer is a facade (a simple front door over different implementations) for application metrics. Spring Boot wires it into Actuator, so your code records numbers once and Micrometer adapts them to the backend you choose. That means the same business code can publish to Prometheus today and another system later with very little change.

How it works under the hood

Spring Boot creates a MeterRegistry, which is the object that stores and exports metrics.
Your code registers a meter, such as a Counter (only goes up), a Gauge (current value), or a Timer (count + duration).
Each metric is keyed by a name plus tags (small labels like status=200 or method=POST).
When business logic runs, the meter updates in constant time, so recording a count or duration is usually O(1).
The registry aggregates the values and exposes them through Actuator endpoints such as /actuator/metrics. If you add a backend registry like Prometheus, Boot also exposes /actuator/prometheus.
The monitoring system either scrapes (pulls) the metrics, as Prometheus does, or receives push updates, which is common for vendor services.

Which meter to choose

Meter	What it means	Best use
Counter	Monotonic total	Requests, errors
Gauge	Current value	Queue size, in-flight work
Timer	Count + duration	Latency, slow calls
DistributionSummary	Value distribution	Payload size, bytes

One practical rule: use Timer for anything that takes time, because it already gives you both a count and duration percentiles in many backends. Use Counter for events that only increase, and use Gauge when you care about the current value, not the history.

Micrometer vs logs vs traces

Tool	Best for	Trade-off
Metrics	Trends and alerts	Low detail
Logs	Exact events	More noise
Traces	Request flow	Often sampled

Production rules of thumb

Keep tags low-cardinality. Good tags: status, method, region. Bad tags: userId, orderId, requestId.
High cardinality means too many unique label combinations, which creates too many time series and can slow Prometheus and inflate memory use.
A real rule of thumb: 1,000 users multiplied by 20 endpoints can become 20,000 time series very quickly.
Use metrics for symptoms you can alert on: latency, error rate, traffic, and saturation. Don’t try to put every debug detail into a metric.
Spring Boot keeps management endpoints off your public API by default, so you usually expose only what you need, such as health, metrics, and maybe prometheus.

Memory angle: think of Micrometer as a scoreboard, not a movie. It tells you the current score and trend, while logs are the play-by-play and traces are the route map.

package com.example.micrometer; import java.time.Instant; import java.util.Map; import java.util.concurrent.ThreadLocalRandom; import java.util.concurrent.atomic.AtomicInteger; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.context.annotation.Bean; import org.springframework.http.HttpStatus; import org.springframework.http.ResponseEntity; import org.springframework.web.bind.annotation.ExceptionHandler; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PostMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; import io.micrometer.core.instrument.Counter; import io.micrometer.core.instrument.Gauge; import io.micrometer.core.instrument.MeterRegistry; import io.micrometer.core.instrument.Timer; // Add spring-boot-starter-actuator, and add micrometer-registry-prometheus if you want /actuator/prometheus. @SpringBootApplication public class MicrometerMonitoringApplication { public static void main(String[] args) { SpringApplication.run(MicrometerMonitoringApplication.class, args); } @Bean CheckoutService checkoutService(MeterRegistry registry) { return new CheckoutService(registry); } @Bean CheckoutController checkoutController(CheckoutService service) { return new CheckoutController(service); } static final class CheckoutService { private final MeterRegistry registry; private final Counter successCounter; private final Counter rejectedCounter; private final Counter failedCounter; private final Timer successTimer; private final Timer rejectedTimer; private final Timer failedTimer; private final AtomicInteger inFlight = new AtomicInteger(); CheckoutService(MeterRegistry registry) { this.registry = registry; // Counters tell us how many events happened over time. this.successCounter = Counter.builder("demo.checkout.requests") .tag("outcome", "success") .description("Successful checkout requests") .register(registry); this.rejectedCounter = Counter.builder("demo.checkout.requests") .tag("outcome", "rejected") .description("Rejected checkout requests") .register(registry); this.failedCounter = Counter.builder("demo.checkout.requests") .tag("outcome", "failed") .description("Failed checkout requests") .register(registry); // Timers record latency; the backend can later compute percentiles and trends. this.successTimer = Timer.builder("demo.checkout.latency") .tag("outcome", "success") .description("Checkout latency") .register(registry); this.rejectedTimer = Timer.builder("demo.checkout.latency") .tag("outcome", "rejected") .description("Checkout latency") .register(registry); this.failedTimer = Timer.builder("demo.checkout.latency") .tag("outcome", "failed") .description("Checkout latency") .register(registry); // A gauge is a current value, so it is perfect for in-flight work. Gauge.builder("demo.checkout.inflight", inFlight, AtomicInteger::get) .description("Requests currently being processed") .register(registry); } Receipt placeOrder(long amount) { inFlight.incrementAndGet(); Timer.Sample sample = Timer.start(registry); Timer chosenTimer = successTimer; try { if (amount <= 0) { // A bad request should still be counted; otherwise you hide the problem. rejectedCounter.increment(); chosenTimer = rejectedTimer; throw new IllegalArgumentException("amount must be positive"); } if (amount > 5000) { // Simulate a downstream failure path that should show up in monitoring. failedCounter.increment(); chosenTimer = failedTimer; throw new IllegalStateException("payment gateway rejected the charge"); } // Simulate real work so the timer records visible latency. Thread.sleep(ThreadLocalRandom.current().nextInt(40, 111)); successCounter.increment(); return new Receipt("ORD-" + System.currentTimeMillis(), amount, Instant.now()); } catch (InterruptedException ex) { Thread.currentThread().interrupt(); failedCounter.increment(); chosenTimer = failedTimer; throw new IllegalStateException("checkout was interrupted", ex); } finally { // Stop the timer even when the request fails; that keeps latency visible. sample.stop(chosenTimer); inFlight.decrementAndGet(); } } int currentInFlight() { return inFlight.get(); } } @RestController @RequestMapping("/orders") static final class CheckoutController { private final CheckoutService service; CheckoutController(CheckoutService service) { this.service = service; } @PostMapping ResponseEntity<Receipt> placeOrder(@RequestParam long amount) { return ResponseEntity.ok(service.placeOrder(amount)); } @GetMapping("/inflight") Map<String, Integer> inflight() { return Map.of("inFlight", service.currentInFlight()); } @ExceptionHandler(IllegalArgumentException.class) ResponseEntity<Map<String, String>> badRequest(IllegalArgumentException ex) { return ResponseEntity.status(HttpStatus.BAD_REQUEST) .body(Map.of("error", ex.getMessage())); } @ExceptionHandler(IllegalStateException.class) ResponseEntity<Map<String, String>> badGateway(IllegalStateException ex) { return ResponseEntity.status(HttpStatus.BAD_GATEWAY) .body(Map.of("error", ex.getMessage())); } } record Receipt(String orderId, long amount, Instant createdAt) {} }

Common Mistakes:

Using high-cardinality tags. Correction: keep labels small and stable; never tag metrics with per-request identifiers.
Choosing the wrong meter. Correction: counters count events, gauges show the current value, and timers measure latency.
Forgetting to expose the endpoint. Correction: Actuator is not enough by itself; you still need to expose the endpoint and, for Prometheus, add the registry dependency.
Ignoring failure paths. Correction: time and count errors too, because outages are exactly when metrics matter most.

Memory Hook: Think of Micrometer as the dashboard for your app: counters are the odometer, gauges are the fuel meter, and timers are the stopwatch.

Cheat Sheet:

Micrometer = vendor-neutral metrics API for Spring Boot.
Spring Boot + Actuator auto-configures a MeterRegistry.
Use counters for totals, gauges for current values, timers for latency.
Prefer low-cardinality tags like status, method, and region.
Prometheus usually scrapes; vendor backends often push or ingest metrics.
Focus on latency, errors, traffic, and saturation.

Practice Tasks:

Add a second endpoint that records a DistributionSummary for payload sizes.
Write a unit test that verifies the rejected counter increases when amount=0.
Temporarily add a bad tag like orderId, then observe how quickly the number of series grows.