0Pricing
Spring Boot 4 Complete Guide · Lekcja

Korelowanie logów, metryk i śladów

Ujednolicaj telemetrię, korelując ustrukturyzowane logi, metryki i ślady w celu szybkiego diagnozowania incydentów

Korelowanie logów, metryk i śladów to bezpłatna lekcja Spring Boot 4 Complete Guide na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Spring Boot 4 Complete Guide, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Spring Boot 4 Complete Guide zawiera 4 lekcji w sumie.

Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.

The Three Pillars Problem

Observability rests on three signal types, each answering a different question:

  • Logs — discrete events: what happened at a point in time.
  • Metrics — aggregated numbers: how much / how often over time.
  • Traces — causal request flow: where time was spent across services.

During an incident, looking at each pillar in isolation is slow. You see a latency spike in a metric, but you cannot jump to the exact logs or the slow span. The goal of this lesson is correlation: stitch the three together so one signal links directly to the others, collapsing diagnosis time from minutes to seconds.

The Glue: trace_id and span_id

The key that unifies all three pillars is the trace context propagated by OpenTelemetry / Micrometer Tracing. Two identifiers matter:

  • traceId — a unique id for the entire request as it crosses services.
  • spanId — a unique id for one unit of work inside that trace.

If every log line, every metric exemplar, and every span carries the same traceId, a single id lets you pivot between pillars. In Spring Boot 4, Micrometer Tracing automatically places these ids into the SLF4J MDC (Mapped Diagnostic Context), so your logs inherit them with zero per-line code.

Wiring Up the Dependencies

To get automatic correlation in a Spring Boot 4 service, you need the Actuator, Micrometer Tracing bridge, and an exporter. The bridge connects Spring observations to a tracer; the exporter ships spans to a backend like Tempo, Jaeger, or Zipkin.

A typical Maven setup:

<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
  </dependency>
  <!-- Bridge Micrometer Observation -> OpenTelemetry tracer -->
  <dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-tracing-bridge-otel</artifactId>
  </dependency>
  <!-- Export spans over OTLP to Tempo/Jaeger -->
  <dependency>
    <groupId>io.opentelemetry</groupId>
    <artifactId>opentelemetry-exporter-otlp</artifactId>
  </dependency>
  <!-- Push metrics to Prometheus -->
  <dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
  </dependency>
</dependencies>

Logs That Carry the Trace Id

Micrometer Tracing injects traceId and spanId into the MDC. To surface them, reference the MDC keys in your logging pattern. Spring Boot 4 ships a convenient property that prepends the application name plus ids:

  • logging.pattern.correlation controls the correlation segment.
  • The values come from MDC keys traceId and spanId.

Example application.yml:

spring:
  application:
    name: orders-service

management:
  tracing:
    sampling:
      probability: 1.0          # sample everything in dev
  otlp:
    tracing:
      endpoint: http://tempo:4318/v1/traces

logging:
  pattern:
    correlation: "[${spring.application.name},%X{traceId:-},%X{spanId:-}] "
  level:
    org.springframework.web: INFO

What a Correlated Log Line Looks Like

With the pattern in place, every log statement automatically prints the trace context. You write ordinary logging code; the ids appear for free because they live in the MDC:

The resulting output looks like:

2026-06-10 09:14:02.331 INFO [orders-service,3f9a1c0b8e4d77a2,8e4d77a2c1b0] o.e.OrderService : Placing order 4821 for customer 77

The middle bracket holds appName,traceId,spanId. Now any human or log query (Loki, Elasticsearch) can filter by traceId and retrieve every line emitted while serving that one request — across threads and even across services.

@Service
public class OrderService {
    private static final Logger log = LoggerFactory.getLogger(OrderService.class);

    public Order place(long customerId, Cart cart) {
        log.info("Placing order for customer {}", customerId);
        Order order = persist(customerId, cart);
        log.info("Order {} confirmed", order.id());
        return order;
    }
}

Reading the MDC Programmatically

Sometimes you need the trace id in code — to return it in an error response so a user can quote it to support, or to attach it to an outgoing message. The ids live in the SLF4J MDC, a thread-local map. You can read them directly:

This is a complete, standalone illustration of how MDC works — no Spring required. In a real service Micrometer populates these keys for you; here we set them manually to show the mechanism.

import org.slf4j.MDC;

public class MdcDemo {
    public static void main(String[] args) {
        // Micrometer Tracing normally sets these per-request.
        MDC.put("traceId", "3f9a1c0b8e4d77a2");
        MDC.put("spanId", "8e4d77a2c1b0");

        String traceId = MDC.get("traceId");
        String spanId = MDC.get("spanId");
        System.out.println("trace=" + traceId + " span=" + spanId);

        // Echo back to the client so they can quote it to support.
        System.out.println("{\"error\":\"failed\",\"traceId\":\"" + traceId + "\"}");

        MDC.clear();
    }
}

Custom Spans with @Observed

Auto-instrumentation covers controllers, RestClient/WebClient, and JDBC. For your own business operations, create explicit observations. The @Observed annotation (from Micrometer) wraps a method in an observation that becomes both a span and a timer metric — one annotation feeds two pillars.

Enable it with an ObservedAspect bean, then annotate:

@Configuration
public class ObservabilityConfig {
    @Bean
    ObservedAspect observedAspect(ObservationRegistry registry) {
        return new ObservedAspect(registry);
    }
}

@Service
public class PricingService {

    @Observed(name = "pricing.calculate",
              contextualName = "calculate-price",
              lowCardinalityKeyValues = {"tier", "premium"})
    public Money calculate(Cart cart) {
        // span 'calculate-price' + timer 'pricing.calculate' emitted automatically
        return cart.lines().stream()
                   .map(Line::subtotal)
                   .reduce(Money.ZERO, Money::add);
    }
}

Exemplars: Linking Metrics to Traces

Metrics are aggregates, so they lose the individual request. Exemplars bridge this gap: a Prometheus histogram bucket can attach a sample traceId for one of the requests that fell into that bucket.

So when you stare at a p99 latency spike in Grafana, you click the exemplar dot on the histogram and jump straight to the offending trace. Micrometer + the Prometheus registry emit exemplars automatically when a tracer is on the classpath.

  • Metric tells you that something is slow.
  • Exemplar gives you one concrete trace id.
  • Trace shows you where the time went.
  • That trace id filters the logs for the full story.

Propagating Context Across Threads

Trace context is stored in a ThreadLocal. When you hand work to an @Async method or an executor, the context does not follow automatically and your child logs lose the traceId.

The fix in Spring Boot 4: wrap your executor with Micrometer's ContextSnapshot support (or use ContextExecutorService). Spring's TaskDecorator integration propagates both the MDC and the observation scope:

@Configuration
@EnableAsync
public class AsyncConfig {

    @Bean
    TaskDecorator otelTaskDecorator() {
        // Re-attaches the captured trace/MDC context inside the worker thread
        return runnable -> {
            var snapshot = io.micrometer.context.ContextSnapshotFactory
                    .builder().build().captureAll();
            return () -> {
                try (var scope = snapshot.setThreadLocals()) {
                    runnable.run();
                }
            };
        };
    }

    @Bean
    Executor taskExecutor(TaskDecorator decorator) {
        var ex = new ThreadPoolTaskExecutor();
        ex.setTaskDecorator(decorator);
        ex.initialize();
        return ex;
    }
}

Correlation Meets Resilience

Resilience patterns and correlation reinforce each other. When a Resilience4j circuit breaker opens or a retry fires, that event should be visible in all three pillars under the same traceId:

  • The span records the fallback and its error tag.
  • A metric (resilience4j.circuitbreaker.calls) counts the failures.
  • The log line, carrying the trace id, explains which downstream call tripped the breaker.

Annotate the fallback path so the failure stays attached to the originating trace:

@Service
public class InventoryClient {
    private static final Logger log = LoggerFactory.getLogger(InventoryClient.class);

    @CircuitBreaker(name = "inventory", fallbackMethod = "fromCache")
    @Retry(name = "inventory")
    public Stock check(String sku) {
        return restClient.get().uri("/stock/{sku}", sku)
                         .retrieve().body(Stock.class);
    }

    private Stock fromCache(String sku, Throwable cause) {
        // Same traceId as the failed call -> diagnosable end to end
        log.warn("inventory call failed for {}, serving cached stock", sku, cause);
        return cache.getOrEmpty(sku);
    }
}

The Diagnosis Workflow

Put it together as a repeatable incident drill. A pager fires on an SLO burn-rate alert built from metrics. From there:

  • Step 1 — Metric: Grafana dashboard shows p99 on http.server.requests spiking for POST /orders.
  • Step 2 — Exemplar: Click the exemplar on the histogram; it carries a traceId.
  • Step 3 — Trace: Open that trace in Tempo; the waterfall shows a 4-second span on the inventory call.
  • Step 4 — Logs: Pivot from the trace to Loki filtered by the same traceId; the warn log reveals a circuit breaker opened after timeouts.

Four clicks, one id, root cause found. That is the payoff of correlation.

Quick Check

Test your understanding of the correlation mechanism.

Recap

You unified the three observability pillars around a single shared key:

  • traceId/spanId propagated by Micrometer Tracing are the glue across logs, metrics, and traces.
  • Logs inherit the ids automatically from the SLF4J MDC via logging.pattern.correlation — no per-line code.
  • @Observed turns one business method into both a span and a timer, feeding traces and metrics at once.
  • Exemplars let a metric spike point to one concrete trace, and that trace id then filters the logs.
  • Context propagation (TaskDecorator / ContextSnapshot) keeps the trace alive across async threads.
  • Resilience events (circuit breaker, retry fallback) stay attached to the originating trace, so failures are diagnosable end to end.

The result is a four-click incident workflow: metric → exemplar → trace → logs, all bound by one id.

Często zadawane pytania

Czy lekcja „Korelowanie logów, metryk i śladów” jest bezpłatna?

Tak — pełny tekst „Korelowanie logów, metryk i śladów” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Spring Boot 4 Complete Guide, przejdź na CoddyKit PRO. Kurs Spring Boot 4 Complete Guide zawiera 4 lekcji w sumie.

Co nauczysz się w „Korelowanie logów, metryk i śladów”?

Ujednolicaj telemetrię, korelując ustrukturyzowane logi, metryki i ślady w celu szybkiego diagnozowania incydentów Ćwiczysz Spring Boot 4 Complete Guide z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Spring Boot 4 Complete Guide?

Nie wymagamy żadnego doświadczenia. Spring Boot 4 Complete Guide w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Korelowanie logów, metryk i śladów”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Spring Boot 4 Complete Guide?

Tak. Każda lekcja Spring Boot 4 Complete Guide zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Propagacja kontekstu i instrumentacja spanów
  2. Circuit breakery i izolacja typu bulkhead
  3. Ograniczanie przepustowości, ponawianie prób i limity czasu
  4. Korelowanie logów, metryk i śladów
← Powrót do Spring Boot 4 Complete Guide