Monitoring means continuously collecting numbers from your running application — so you can see problems as they happen, not after a user complains.
You ship a feature. The deploy goes green. Everything looks fine. Then Slack lights up: 'The lesson generator seems stuck.' You open the logs. Thousands of lines scroll by. No stack trace jumps out. You grep for ERROR — a few noise hits, nothing that matches. You ask your teammate: 'Was it slow yesterday?' They shrug. You have no baseline. No numbers. No timeline. Just a feeling that something is wrong. This is what it feels like to run a production system without monitoring. The frustrating part? The answer was there the whole time — hidden inside your running JVM, waiting to be collected. You just never asked for it. So: what exactly should you be collecting, and how do you make it visible before someone on Slack has to tell you something is wrong?
Think about a car dashboard. Your car doesn't wait for the engine to explode before telling you something is wrong. It continuously measures things — speed, fuel level, engine temperature — and shows them to you in real time. When something crosses a threshold, a warning light turns on. That's monitoring. In software, monitoring means: while your application is running, it continuously counts and measures things about itself, and exposes those numbers so you — or an automated alert — can look at them. Those numbers are called metrics . A metric is just a number with a name and a timestamp. Examples: - http requests total — how many HTTP requests have been handled - lesson generation duration seconds — how long the lesson pipeline took - db connections active…
Step 1 — The app starts up. Imagine your Spring Boot service as a building. The moment it starts, Micrometer installs tiny counters and timers on every door and hallway. You can't see them yet — they're just quietly ticking. Step 2 — A request arrives. A learner asks the AI tutor a question. The request enters your app. Micrometer's counter for http requests total increments by one. A stopwatch starts for tutor response duration seconds . Step 3 — The LLM call happens. Your app calls Amazon Bedrock (Claude). That call takes 1.8 seconds. When it returns, Micrometer stops the stopwatch and records: 1.8 seconds, for the 'tutor' endpoint. Step 4 — The response goes back to the learner. The request is done. All the counters have been updated. Nothing has been sent anywhere yet — the numbers are just sitting inside the JVM's memory, waiting. Step 5 — Prometheus comes knocking.…