PPalabas APIJava field course

Module 6 / Lesson 6.1

Observability as a Debugging Story

Add correlation IDs, structured logs, Prometheus metrics, and cache evidence that answer real debugging questions.

Concept

Observability is not a dependency list. It is the ability to answer a question after something goes wrong. Phase 6 makes request identity, status, timing, cache behavior, and database path visible enough to reconstruct an incident.

Task

  1. Expose health and info publicly, and keep Prometheus available only to authenticated scrapes.
  2. Add ECS structured logging and a correlation-ID filter backed by MDC.
  3. Add a Caffeine-backed showtime read path and a custom hit/miss metric.
  4. Prove eviction after writes with a Testcontainers-backed test.
  5. Write two transcripts that start from debugging questions.

Run

./gradlew test --tests "*CorrelationIdFilterTest"
./gradlew test --tests "*DemoReadOnlyProfileTest"
./gradlew dockerTest --tests "*ShowtimeObservabilityTest"

Expected Result

  • The Prometheus endpoint contains `palabas_showtime_lookups_total`.
  • The transcripts can locate status, endpoint, timing, and cache result without reading source code.

Common Traps

  • Adding Actuator and calling that observability.
  • Logging request IDs without returning them to the caller.
  • Caching reads without naming the write path that invalidates them.

Hint Ladder

Hint 1

Start from the incident question, then choose the metric or log field.

Hint 2

MDC only matters if the log format includes it.

Hint 3

A cache test should prove both hit/miss behavior and eviction.

Solution

See observability-notes.md and ShowtimeObservabilityTest.java.

Boot 3 to 4 Delta

Boot 4 keeps Actuator and Micrometer familiar while adding first-class structured logging settings. The course uses that native logging path instead of adding a logging framework detour.