Requests flow Client → API Gateway → Order Service → Inventory — traces, metrics, and logs update on every hop
Every request gets a unique traceId propagated as a W3C traceparent header. OpenTelemetry auto-instrumentation captures a span for each service hop, HTTP client call, and database query — providing the full request waterfall without any manual annotation code.
Micrometer exposes Prometheus-compatible metrics from each service: request rate, error rate, JVM heap, thread pool saturation, and business metrics like order throughput. Prometheus scrapes every 15 seconds; Grafana dashboards page on SLO breach.
All services emit structured JSON (Logback + LogstashEncoder) with traceId and spanId injected via MDC on every log line. One traceId search in Loki returns both the span waterfall and every log line the request produced — across all three services simultaneously.
The three pillars of observability — all correlated by traceId. · See the CI/CD pipeline that deploys this → · Need this built?
About this demo
Observability in distributed systems rests on three pillars: metrics (aggregated numerical measurements over time), traces (the path of a single request across services), and logs (structured event records with context). This simulator shows all three being emitted simultaneously by a running Spring Boot microservice under load.
Spring Boot Actuator exposes metrics via Micrometer, which can export to Prometheus and visualise in Grafana. Distributed tracing with OpenTelemetry correlates log entries and spans across service boundaries using a shared trace ID — so when a request fails, you can follow it from the API gateway through every downstream call. Structured JSON logging ties the trace ID to every log line, enabling log aggregation tools like Loki or CloudWatch Logs Insights to filter by request in a single query.