Hur man använder Spring Boot 3.4 för att sprida spår från anpassade rubriker

Hantera anpassade rubrikspår i Spring Boot 3.4

Föreställ dig att du har en webbtjänst Spring Boot 3.4 som fungerar sömlöst med två klienter. Den första klienten använder Spring Boot 3+, vilket gör spårspridning till en lek. Utan någon extra ansträngning får du vacker änd-till-ände spårkontinuitet 🪄. Loggar verkar rena och sammankopplade, som genom ett magi.

Saker och ting tar dock en vändning när klient två kommer till spel. Istället för vanliga spårningsrubriker skickar de anpassade rubriker som "ot-custom-traceid" och "ot-custom-spanid". Även om dessa anpassade rubriker innehåller giltig spårningsinformation, kan Spring Boot inte sprida dessa spår. Resultatet? Du förlorar möjligheten att koppla klientspår med loggar på serversidan.

Detta skapar en observerbarhetsklyfta. För klient ett ser du hela sökvägen för en förfrågan över tjänster. För klient två ser du bara loggar på serversidan, saknar det kritiska klientspåret. Det är som att se ett halvt pussel – du vet att något saknas men kan inte sätta ihop bitarna. 😓

I den här artikeln kommer vi att utforska hur man löser det här problemet utan att förlita sig på Spring Cloud Sleuth, och förblir trogen Spring Boot 3.4-ekosystemet. I slutet kommer du att veta hur du sprider och fortsätter spår från anpassade rubriker, vilket säkerställer sömlös observerbarhet i hela ditt system.

Kommando	Exempel på användning
MDC.put	Det här kommandot lägger till nyckel-värdepar till Mapped Diagnostic Context (MDC), vilket gör att anpassade spårnings-ID:n kan inkluderas i loggar. Till exempel MDC.put("traceId", "12345").
MDC.clear	Rensar alla poster från MDC efter att en begäran har behandlats för att undvika spårkontamination mellan förfrågningar. Till exempel MDC.clear().
OncePerRequestFilter	Ett Spring Boot-filter som säkerställer att filterlogiken endast exekveras en gång per HTTP-begäran, perfekt för att spåra rubriker. Exempel: public class CustomTraceFilter utökar OncePerRequestFilter.
filterChain.doFilter	Fortsätter till nästa filter i kedjan och säkerställer att begäran fortsätter genom andra filter. Till exempel filterChain.doFilter(request, response).
RestTemplate.getInterceptors()	Hämtar listan över interceptorer för en RestTemplate-instans, vilket gör att anpassade interceptorer kan läggas till. Exempel: restTemplate.getInterceptors().add(new CustomInterceptor()).
ClientHttpRequestInterceptor	Ett gränssnitt för att avlyssna utgående HTTP-förfrågningar och lägga till anpassade rubriker. Till exempel implementera ClientHttpRequestInterceptor för att infoga spårnings-ID:n.
HttpServletRequest.getHeader	Extraherar värdet för en specifik HTTP-rubrik från den inkommande begäran. Exempel: request.getHeader("ot-custom-traceid").
FilterRegistrationBean	Registrerar anpassade filter i Spring Boot-applikationen. Till exempel: registrationBean.setFilter(new CustomTraceFilter()).
MockMvc.perform	Simulerar HTTP-förfrågningar i enhetstester för Spring Boot-applikationer. Exempel: mockMvc.perform(get("/test-endpoint").header("ot-custom-traceid", "12345")).
ClientHttpRequestExecution.execute	Utför den avlyssnade HTTP-begäran med den angivna begärantexten och rubrikerna. Exempel: execution.execute(request, body).

Anpassad header-spårförökning i fjäderstart

En av nyckelkomponenterna för att lösa det här problemet är CustomTraceFilter. Detta filter förlänger klass, vilket säkerställer att logiken för spårningshuvudet endast körs en gång för varje HTTP-begäran. Filter i Spring Boot är otroligt användbara när du ändrar förfrågningar eller svar globalt. Till exempel om klienten skickar spårningsinformation som eller i anpassade rubriker fångar detta filter upp begäran, extraherar dessa rubriker och sprider dem till Mapped Diagnostic Context (MDC). Genom att lägga till spårnings-ID:n till MDC:n säkerställer vi att dessa identifierare är synliga i loggarna som genereras under förfrågningsbehandlingen.

MDC är en kritisk del av loggningsramverk som SLF4J och Logback. Det tillåter oss att lagra kontextuell information för den aktuella tråden, till exempel anpassade spårnings-ID:n. Använda kommandon som och , säkerställer vi att loggningssystemet inkluderar spårningsdetaljerna och undviker kontaminering mellan samtidiga förfrågningar. Till exempel, om klient två skickar `ot-custom-traceid` som `8f7ebd8a73f9a8f50e6a00a87a20952a`, lagras detta ID i MDC och inkluderas i alla nedströmsloggar, vilket skapar en konsekvent spårningsväg.

Å andra sidan, för utgående HTTP-förfrågningar, spelar RestTemplate interceptor en viktig roll. Genom att implementera , kan vi bifoga samma spårningsrubriker (`ot-custom-traceid` och `ot-custom-spanid`) till utgående förfrågningar. Detta säkerställer att spårningskontinuiteten upprätthålls när applikationen anropar andra mikrotjänster. Till exempel, när servern bearbetar en begäran med spårnings-ID `8f7ebd8a73f9a8f50e6a00a87a20952a`, bifogar den detta ID till de utgående rubrikerna, så att nedströmstjänster kan känna igen och sprida spåret sömlöst.

Slutligen validerar enhetstesten skrivna med MockMvc hela installationen genom att simulera HTTP-förfrågningar och verifiera header-utbredning. I verkliga tillämpningar är testning avgörande för att säkerställa att spårningshuvuden hanteras korrekt. Till exempel, genom att skicka en GET-förfrågan med anpassade rubriker och inspektera svaret eller loggarna, kan vi bekräfta att filtret och interceptorn fungerar som förväntat. Detta omfattande tillvägagångssätt löser utmaningen utan att förlita sig på äldre beroenden som Spring Cloud Sleuth. I slutändan säkerställer kombinationen av filter, interceptorer och MDC spårningskontinuitet även när klienter använder anpassade rubriker, vilket gör systemet robust och fullt observerbart. 🌟

// Solution 1: Extract and Propagate Custom Trace Headers Manually
// Import necessary Spring Boot and Micrometer libraries
import org.slf4j.MDC;
import org.springframework.http.HttpHeaders;
import org.springframework.web.filter.OncePerRequestFilter;
import javax.servlet.FilterChain;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

public class CustomTraceFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
            throws IOException {
        String traceId = request.getHeader("ot-custom-traceid");
        String spanId = request.getHeader("ot-custom-spanid");
        try {
            if (traceId != null) {
                MDC.put("traceId", traceId); // Add traceId to Mapped Diagnostic Context
            }
            if (spanId != null) {
                MDC.put("spanId", spanId);
            }
            filterChain.doFilter(request, response); // Continue request processing
        } finally {
            MDC.clear(); // Ensure MDC is cleared after processing
        }
    }
}

// Register the filter in your configuration class
@Configuration
public class FilterConfig {
    @Bean
    public FilterRegistrationBean<CustomTraceFilter> traceFilter() {
        FilterRegistrationBean<CustomTraceFilter> registrationBean = new FilterRegistrationBean<>();
        registrationBean.setFilter(new CustomTraceFilter());
        registrationBean.addUrlPatterns("/*");
        return registrationBean;
    }
}

// Import necessary libraries
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest;
import org.springframework.test.web.servlet.MockMvc;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;

@WebMvcTest
public class CustomTraceFilterTest {
    @Autowired
    private MockMvc mockMvc;

    @Test
    public void testCustomTraceHeaders() throws Exception {
        mockMvc.perform(get("/test-endpoint")
                .header("ot-custom-traceid", "12345")
                .header("ot-custom-spanid", "67890"))
                .andExpect(status().isOk());
    }
}

// Import necessary libraries
import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpRequest;
import org.springframework.http.client.ClientHttpRequestExecution;
import org.springframework.http.client.ClientHttpRequestInterceptor;
import org.springframework.http.client.ClientHttpResponse;
import org.springframework.web.client.RestTemplate;
import java.io.IOException;

public class CustomHeaderInterceptor implements ClientHttpRequestInterceptor {
    @Override
    public ClientHttpResponse intercept(HttpRequest request, byte[] body, ClientHttpRequestExecution execution) throws IOException {
        HttpHeaders headers = request.getHeaders();
        headers.add("ot-custom-traceid", "12345");
        headers.add("ot-custom-spanid", "67890");
        return execution.execute(request, body);
    }
}

// Register the interceptor with RestTemplate
@Configuration
public class RestTemplateConfig {
    @Bean
    public RestTemplate restTemplate() {
        RestTemplate restTemplate = new RestTemplate();
        restTemplate.getInterceptors().add(new CustomHeaderInterceptor());
        return restTemplate;
    }
}

Hantera anpassade rubrikspår med OpenTelemetry i Spring Boot 3.4

När du arbetar med Spring Boot 3.4 är en annan kraftfull metod för att sprida spår från anpassade rubriker genom att integrera . OpenTelemetry, ett ramverk för observerbarhet med öppen källkod, hjälper till att instrumentera, samla in och exportera spår sömlöst. Det tillhandahåller mekanismer för att extrahera och injicera spårningskontext, inklusive anpassade rubriker som och , i din ansökan. Genom att utnyttja OpenTelemetrys TextMapPropagator kan du överbrygga klyftan mellan icke-standardiserade klienter och ditt observerbarhetssystem.

För att använda OpenTelemetry i Spring Boot 3.4 kan en anpassad propagator implementeras för att extrahera spårningsinformation från de anpassade rubrikerna och bifoga den till den aktuella spårningskontexten. Till exempel, när din server tar emot en inkommande begäran från klient två, kan OpenTelemetry analysera anpassade rubriker och rekonstruera det ursprungliga spårningskontexten. Detta säkerställer att nedströmstjänster ser samma spårnings-ID:n, vilket möjliggör synlighet från slut till ände. Till skillnad från äldre lösningar som Spring Cloud Sleuth är OpenTelemetry lätt och anpassar sig till moderna observerbarhetsstandarder.

Genom att kombinera OpenTelemetrys propagator med Micrometer kan du berika dina mätvärden och loggning med spårningsinformation. Föreställ dig att se spår efter förfrågningar som kommer från både Client One och Client Two sömlöst i ditt observerbarhetsverktyg. OpenTelemetry stöder automatiskt integrationer med Prometheus, Zipkin eller Jaeger, vilket gör att du kan centralisera spårvisualisering. Detta tillvägagångssätt säkerställer att ingen spårningsdata går förlorad även när anpassade rubriker är inblandade och att felsökningen blir betydligt enklare. 🚀

1. Hur extraherar jag manuellt anpassade spårningsrubriker i Spring Boot?
2. Du kan använda request.getHeader("custom-header") för att manuellt hämta en specifik rubrik och lägga till den i MDC med MDC.put("traceId", värde).
3. Vad är fördelen med att använda OpenTelemetry för anpassad spårspridning?
4. OpenTelemetry ger en modern, leverantörsneutral metod för att sprida spår, inklusive anpassade rubriker, över mikrotjänster.
5. Kan jag sprida anpassade rubriker med RestTemplate i Spring Boot?
6. Ja, genom att implementera en ClientHttpRequestInterceptor kan du bifoga anpassade rubriker som traceid och spanid till utgående förfrågningar.
7. Hur registrerar jag ett filter för att fånga rubriker globalt?
8. Du kan skapa ett filter som utökar OncePerRequestFilter och registrera det med FilterRegistrationBean för att fånga rubriker för alla slutpunkter.
9. Vilka verktyg kan jag använda för att visualisera spår från Spring Boot?
10. Verktyg som Zipkin, Jaeger och Prometheus kan integreras med Spring Boot och OpenTelemetry för att visualisera spår från ände till ände.

I moderna system är hantering av anpassade spårningshuvuden avgörande för tillförlitlig observerbarhet. Genom att använda filter och interceptorer kan du fånga spårningsinformation från klienten och sprida den korrekt över dina tjänster. Detta undviker fragmenterade stockar och saknade spår. 🔍

Spring Boot 3.4, kombinerat med Micrometer eller OpenTelemetry, tillåter robusta lösningar utan att förlita sig på äldre verktyg som Spring Cloud Sleuth. Oavsett om du har att göra med Client Ones standardhuvuden eller Client Twos anpassade rubriker, överbryggar implementeringen av dessa tekniker spårningsgaporna effektivt. 🚀