Observability Fundamentals
Why Microservices Need Observability
A customer says "my order failed at 9:42 PM". In a monolith you open one log file. In ShopEase microservices the request went through the gateway, order-service, inventory-service, payment-service and Kafka, with 3 instances each. Without help, you are searching 15 log files on 15 containers.
Observability means you can answer new questions about the running system from the data it emits, without adding new code first.
The Three Pillars
| Pillar | Answers | Spring tool | Backend |
|---|---|---|---|
| Logs | What exactly happened in this service? | SLF4J + Logback, structured JSON logs | ELK (Elasticsearch, Logstash, Kibana), Grafana Loki |
| Metrics | How many, how fast, how full? (numbers over time) | Micrometer + Actuator | Prometheus + Grafana |
| Traces | Which services did ONE request touch, and where was time spent? | Micrometer Tracing (Brave or OpenTelemetry bridge) | Zipkin, Jaeger, Grafana Tempo |
order-service, payment-service, ... (each instance)
| logs (JSON) | /actuator/prometheus | spans
v v v
Loki / Elasticsearch Prometheus (scrapes) Zipkin / Tempo
\ | /
+-------------------> Grafana <----------------+
dashboards, alerts, "jump from log to trace"Note: The glue between the pillars is the trace ID: it appears in every log line and every span of a request, so you can jump from an error log to the full trace.
Golden Signals to Watch
| Signal | Example metric for order-service | Alert when |
|---|---|---|
| Latency | p95 of http_server_requests_seconds | p95 > 800 ms for 5 min |
| Traffic | requests per second | drops to 0 (something upstream broke) |
| Errors | rate of 5xx responses | > 1% for 5 min |
| Saturation | HikariCP active connections, JVM heap, CPU | pool 100% used, heap > 90% |
Tip: Spring Boot Actuator basics (health, metrics endpoints, custom health indicators) are covered in the Spring Boot material. Here we focus on what changes when there are many services.