Observability is the practice of instrumenting your application so you can answer questions about its internal state by looking at the data it emits — no guessing, no SSH, no log-grep marathons.
It's a Tuesday afternoon. The EngineerPrep AI tutor just shipped a new lesson-generation feature. A user reports it feels sluggish. You open the AWS console. The EC2 instance is healthy. Spring Boot is up. No ERROR lines in CloudWatch. Your first instinct: maybe it's the user's internet? So you wait. Another user reports the same thing. You SSH into the box and run top . CPU is 12%. Memory is fine. The JVM heap looks normal. And yet — something is slow. The problem isn't that your system is broken. The problem is that your system is silent . It isn't telling you what it's doing, how long each step takes, or where time is disappearing. That silence is what observability fixes. By the end of this lesson you'll know exactly what to add so that the next time this happens, you can answer the question in under a minute.
Think about your car's dashboard. You can't see inside the engine while you're driving. But the dashboard shows you speed, temperature, fuel level, and a warning light if something is wrong. You don't open the hood — you read the signals the engine sends out . Observability is the same idea for software. You can't pause a running Spring Boot service and inspect its memory. But you can make the service emit signals continuously — and then read those signals from the outside. Those signals come in three flavors. Engineers call them the three pillars : Logs are text messages your code writes as it runs. "Generating lesson plan for topic: Redis" is a log. They tell you what happened . Metrics are numbers measured over time. lesson generation duration seconds = 4.2 is a metric. They tell you how much or how long . Traces are a record of one request's journey through your system…
Imagine a horizontal timeline. A learner clicks 'Generate Lesson' in their browser. That single click starts a journey. Step 1 — The request arrives. A box labeled LessonController lights up on the left side of the timeline. A log line appears above it: INFO LessonController - Received lesson request: topic=Redis . That's your first log. It tells you the request existed. Step 2 — The plan phase begins. An arrow leaves LessonController and hits a box labeled LessonPlanService . Another log appears: INFO LessonPlanService - Calling Bedrock for plan . The clock starts ticking on a timer bar stretching to the right. Step 3 — The Bedrock call returns. The timer bar stops. It's 1.8 seconds long. A metric is emitted: bedrock.call.duration{phase=plan} = 1.8s . You can now see how long the plan step took. Step 4 — The author phase runs, then precision-review.…