Micrometer Monitoring.

Micrometer is the dashboard wiring behind Spring Boot production apps: it turns raw app behavior into numbers you can alert on.

Question: What is Micrometer monitoring in Spring Boot?

Answer: Micrometer is a vendor-neutral metrics library. In Spring Boot, it sits behind Actuator and lets you record things like request counts, error rates, and latency, then export them to systems such as Prometheus, Datadog, or CloudWatch. It works best for the question, “How is the system behaving right now?”

Interview-Ready Answer: I use Micrometer as Spring Boot’s metrics layer. It gives me counters, gauges, and timers, and Spring Boot auto-configures a MeterRegistry so I can publish to backends like Prometheus without hard-coding one vendor. In production, I rely on it for fast signals like latency, error rate, and saturation, and I keep tags low-cardinality so the metrics stay cheap and usable.

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

1. Spring Boot creates a MeterRegistry, which is the object that stores and exports metrics.
2. Your code registers a meter, such as a Counter (only goes up), a Gauge (current value), or a Timer (count + duration).
3. Each metric is keyed by a name plus tags (small labels like status=200 or method=POST).
4. When business logic runs, the meter updates in constant time, so recording a count or duration is usually O(1).
5. 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.
6. 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

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

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.

Real-World Story: Imagine a checkout service in an e-commerce app. The team uses Micrometer to track request latency, payment failures, and the number of requests currently in flight. A dashboard shows the 95th percentile latency rising from 120 ms to 900 ms after a deployment, and an alert fires before customers fully complain.

The incident that often happens is a bad tag choice: someone adds orderId to a metric “for debugging.” At first the dashboard looks fine, but Prometheus suddenly has thousands or millions of series, scrapes slow down, memory usage rises, and alerts start timing out. Users see slow checkout pages, logs show scrape warnings, and the ops team realizes the monitoring layer became part of the outage.

The lesson is simple: metrics should summarize the system, not uniquely identify every request.

Follow-up & Tricky Questions:

• How is Micrometer different from Prometheus? Micrometer is the instrumentation API in your app; Prometheus is one possible backend that scrapes the metrics. In an interview, say that Micrometer standardizes how you record metrics, while Prometheus stores and queries them.
• What is the difference between a Counter, Gauge, and Timer? A Counter only increases, a Gauge shows a current value, and a Timer records both count and duration. Timers are usually the best default for latency-sensitive code.
• How do you expose Micrometer metrics in Spring Boot? Add spring-boot-starter-actuator, expose the endpoints you need, and add a backend registry such as Prometheus if you want scrape-based export. Then use /actuator/metrics for inspection and /actuator/prometheus for scraping.
• What is cardinality, and why does it matter? Cardinality is the number of distinct tag combinations. High cardinality creates too many time series, which increases memory use, slows scrapes, and makes dashboards noisy.
• How would you test metrics? Inject a MeterRegistry in a test, call the business method, and assert the counter or timer values. That checks the instrumentation without needing a real monitoring server.
• Tricky: Can I decrement a Counter? No. A counter is monotonic, so it only goes up. If you need a value that rises and falls, use a Gauge.
• Tricky: Is it okay to tag metrics with requestId or userId? Usually no. Those values create massive cardinality and can crush your monitoring backend; use stable tags like status, method, and region instead.
• Tricky: Does Micrometer keep the whole history of the metric? No. Micrometer records and exposes current measurements; the long-term history lives in the monitoring backend like Prometheus or Datadog.

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.