Learn Spring Boot - Observability & Production Support

#Introduction

In episode 9 you built basic observability with the Actuator and Micrometer. In microservices with many services, that isn't enough — you need to trace a single request across many services, correlate logs between components, and act quickly when incidents happen. Episode 22 covers observability and production support.

You'll learn distributed tracing with OpenTelemetry, centralized logging with structured logs, comprehensive health and metrics monitoring, and incident management practices.

#Distributed Tracing with OpenTelemetry

#Why Tracing Is Needed

In a microservices architecture, one user request can pass through five services. When the application is slow, which service is losing the time? Distributed tracing answers this by tracking each request across the entire system — every hop has a span with start and end times.

OpenTelemetry is the open-source standard for tracing, metrics, and logs. Spring Boot 3 has native integration through Micrometer Tracing:

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-tracing-bridge-otel</artifactId>
</dependency>
<dependency>
    <groupId>io.opentelemetry</groupId>
    <artifactId>opentelemetry-exporter-otlp</artifactId>
</dependency>

With these two dependencies, Spring sends traces to the OpenTelemetry collector automatically.

#Trace and Span

A trace represents one end-to-end request and consists of many spans — each span is a unit of work, for example an HTTP call or a database query. Every span carries context: traceId and spanId, propagated from one service to the next through HTTP headers.

management:
  tracing:
    sampling:
      probability: 1.0
  otlp:
    tracing:
      endpoint: http://otel-collector:4317

Click a single trace in Jaeger or Grafana Tempo, and you see the full map: which service is slow, which query is expensive, and how long each hop takes.

#Centralized Logging and Structured Logs

#Structured Logging

A structured log is written in a structured format — usually JSON — so machines can parse and search it quickly. Spring Boot 3 supports JSON logging with logback-encoder or YAML configuration:

logging:
  pattern:
    console: '{"timestamp":"%d{ISO8601}","level":"%level","logger":"%logger{36}","message":"%msg"}'

Every log line becomes a JSON object ready to be sent to a log aggregator like Loki, Elasticsearch, or Datadog.

#Correlation IDs for Relating Logs

Structured logs alone aren't enough — logs must be linkable to traces. When tracing is active, Spring adds traceId and spanId to logs automatically. This is log correlation: search one traceId in the logs and see all the activity related to a single request:

{"timestamp":"2026-08-10T08:00:00Z","level":"INFO",
 "logger":"com.example.ItemService","traceId":"abc123def456",
 "spanId":"789ghi","message":"Membuat item baru: Laptop"}

With a traceId in both logs and traces, you can move from a suspicious log line to a full trace visualization — an invaluable tool when debugging in production.

#Monitoring Health and Metrics

#Dashboards from Metrics

The metrics exported by Micrometer (episode 9) are visualized with Grafana. A good dashboard shows:

• RED method: Rate (number of requests), Error (number of errors), Duration (latency).
• JVM metrics: heap usage, GC pauses, thread count.
• Database: active connection pool, query latency.
• Infrastructure: CPU, memory, disk.

curl -s http://localhost:8080/actuator/prometheus | grep jvm_memory_used

The command curl -s http://localhost:8080/actuator/prometheus | grep jvm_memory_used shows JVM memory usage from Prometheus's perspective. Combine it with alert rules — for example, an alert when the error rate exceeds 1% for 5 minutes.

#Meaningful Alerts

Don't create alerts for everything — focus on symptoms that impact users. Examples of good rules: p99 latency above a threshold, a high error rate, or a health check going down. Every alert should have a runbook: clear diagnostic steps for the on-call engineer.

#Incident Management and Readiness/Liveness

#The Incident Handling Process

When an application misbehaves, a structured flow speeds up recovery:

1. Detection — alerts from metrics or health checks.
2. Diagnosis — dig through traces and logs to find the root cause.
3. Mitigation — roll back, scale out, or apply a quick fix.
4. Post-incident — write a postmortem and follow-ups.

#Readiness vs Liveness in Production

Understanding these two probes correctly prevents self-inflicted incidents:

• Readiness probe — you're ready to receive traffic. If it fails, the pod is removed from the Service but not restarted. A down readiness can be normal — for example when the application is overloaded.
• Liveness probe — you're still alive. If it fails, the pod is restarted. A misconfigured liveness probe can trigger a restart loop when the application is merely slow.

Use a readiness probe with a check that reflects actual readiness (for example the database), and a liveness probe with the most basic check (process alive). Getting these two wrong is one of the most common causes of production incidents in Kubernetes.

#Closing

Episode 22 equipped you with observability and production support: distributed tracing with OpenTelemetry, centralized logging with structured logs and correlation IDs, health and metrics monitoring with Grafana and alerts, and incident management practices with a correct understanding of readiness and liveness.

Key takeaways:

• OpenTelemetry traces requests end to end across services with traces and spans.
• A traceId in logs correlates logs with trace visualizations.
• Structured JSON logs make searching easy in log aggregators.
• Metrics are visualized in Grafana with RED and JVM metrics.
• Alerts must be meaningful and come with a clear runbook.
• Readiness decides when to receive traffic; liveness decides when to restart.

In episode 23 — the final episode — we'll discuss stable modern features and the ecosystem — the stable features of Spring Boot 3.x, native support and observability, the Spring Cloud, Data, and Security ecosystem, and best practices for keeping applications future-proof.