ಕಸ್ಟಮ್ ಹೆಡರ್‌ಗಳಿಂದ ಟ್ರೇಸ್‌ಗಳನ್ನು ಪ್ರಚಾರ ಮಾಡಲು ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್ 3.4 ಅನ್ನು ಹೇಗೆ ಬಳಸುವುದು

ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್ 3.4 ರಲ್ಲಿ ಕಸ್ಟಮ್ ಹೆಡರ್ ಟ್ರೇಸ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು

ನೀವು ಎರಡು ಕ್ಲೈಂಟ್‌ಗಳೊಂದಿಗೆ ಮನಬಂದಂತೆ ಕೆಲಸ ಮಾಡುವ ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್ 3.4 ವೆಬ್ ಸೇವೆಯನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಮೊದಲ ಕ್ಲೈಂಟ್ ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್ 3+ ಅನ್ನು ಬಳಸುತ್ತದೆ, ಇದು ಟ್ರೇಸ್ ಪ್ರಸರಣವನ್ನು ತಂಗಾಳಿಯಲ್ಲಿ ಮಾಡುತ್ತದೆ. ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಪ್ರಯತ್ನವಿಲ್ಲದೆ, ನೀವು ಸುಂದರವಾದ ಅಂತ್ಯದಿಂದ ಕೊನೆಯವರೆಗೆ ಜಾಡಿನ ನಿರಂತರತೆಯನ್ನು ಪಡೆಯುತ್ತೀರಿ 🪄. ಲಾಗ್‌ಗಳು ಮ್ಯಾಜಿಕ್‌ನಂತೆ ಸ್ವಚ್ಛವಾಗಿ ಮತ್ತು ಸಂಪರ್ಕಿತವಾಗಿ ಗೋಚರಿಸುತ್ತವೆ.

ಆದಾಗ್ಯೂ, ಕ್ಲೈಂಟ್ ಎರಡು ಕಾರ್ಯರೂಪಕ್ಕೆ ಬಂದಾಗ ವಿಷಯಗಳು ತಿರುವು ಪಡೆಯುತ್ತವೆ. ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಟ್ರೇಸಿಂಗ್ ಹೆಡರ್‌ಗಳ ಬದಲಿಗೆ, ಅವರು `ot-custom-traceid` ಮತ್ತು `ot-custom-spanid` ನಂತಹ ಕಸ್ಟಮ್ ಹೆಡರ್‌ಗಳನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ. ಈ ಕಸ್ಟಮ್ ಹೆಡರ್‌ಗಳು ಮಾನ್ಯವಾದ ಜಾಡಿನ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿರುವಾಗ, ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್ ಈ ಕುರುಹುಗಳನ್ನು ಪ್ರಚಾರ ಮಾಡಲು ವಿಫಲವಾಗಿದೆ. ಫಲಿತಾಂಶ? ಕ್ಲೈಂಟ್ ಟ್ರೇಸ್‌ಗಳನ್ನು ಸರ್ವರ್ ಸೈಡ್ ಲಾಗ್‌ಗಳೊಂದಿಗೆ ಸಂಪರ್ಕಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ನೀವು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ.

ಇದು ವೀಕ್ಷಣೆಯ ಅಂತರವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಒಂದಕ್ಕೆ, ಸೇವೆಗಳಾದ್ಯಂತ ವಿನಂತಿಯ ಸಂಪೂರ್ಣ ಮಾರ್ಗವನ್ನು ನೀವು ನೋಡುತ್ತೀರಿ. ಎರಡು ಕ್ಲೈಂಟ್‌ಗಾಗಿ, ನೀವು ಸರ್ವರ್-ಸೈಡ್ ಲಾಗ್‌ಗಳನ್ನು ಮಾತ್ರ ನೋಡುತ್ತೀರಿ, ನಿರ್ಣಾಯಕ ಕ್ಲೈಂಟ್ ಟ್ರೇಸ್ ಅನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೀರಿ. ಇದು ಅರ್ಧ ಒಗಟನ್ನು ನೋಡಿದಂತಿದೆ-ಏನೋ ಕಾಣೆಯಾಗಿದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದೆ ಆದರೆ ತುಣುಕುಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸೇರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. 😓

ಈ ಲೇಖನದಲ್ಲಿ, ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್ 3.4 ಪರಿಸರ ವ್ಯವಸ್ಥೆಗೆ ನಿಜವಾಗಿ ಉಳಿಯುವ ಮೂಲಕ ಸ್ಪ್ರಿಂಗ್ ಕ್ಲೌಡ್ ಸ್ಲೀತ್ ಅನ್ನು ಅವಲಂಬಿಸದೆ ಈ ಸಮಸ್ಯೆಯನ್ನು ಹೇಗೆ ಪರಿಹರಿಸಬೇಕೆಂದು ನಾವು ಅನ್ವೇಷಿಸುತ್ತೇವೆ. ಕೊನೆಯಲ್ಲಿ, ನಿಮ್ಮ ಸಿಸ್ಟಂನಾದ್ಯಂತ ತಡೆರಹಿತ ವೀಕ್ಷಣೆಯನ್ನು ಖಾತ್ರಿಪಡಿಸುವ ಮೂಲಕ ಕಸ್ಟಮ್ ಹೆಡರ್‌ಗಳಿಂದ ಕುರುಹುಗಳನ್ನು ಹೇಗೆ ಪ್ರಚಾರ ಮಾಡುವುದು ಮತ್ತು ಮುಂದುವರಿಸುವುದು ಎಂದು ನಿಮಗೆ ತಿಳಿಯುತ್ತದೆ.

ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್‌ನಲ್ಲಿ ಕಸ್ಟಮ್ ಹೆಡರ್ ಟ್ರೇಸ್ ಪ್ರಸರಣ

ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವಲ್ಲಿ ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ CustomTraceFilter. ಈ ಫಿಲ್ಟರ್ ವಿಸ್ತರಿಸುತ್ತದೆ OnePerRequestFilter ವರ್ಗ, ಟ್ರೇಸ್ ಹೆಡರ್ ಲಾಜಿಕ್ ಪ್ರತಿ HTTP ವಿನಂತಿಗೆ ಒಮ್ಮೆ ಮಾತ್ರ ರನ್ ಆಗುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಜಾಗತಿಕವಾಗಿ ವಿನಂತಿಗಳು ಅಥವಾ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಮಾರ್ಪಡಿಸುವಾಗ ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್‌ನಲ್ಲಿರುವ ಫಿಲ್ಟರ್‌ಗಳು ನಂಬಲಾಗದಷ್ಟು ಉಪಯುಕ್ತವಾಗಿವೆ. ಉದಾಹರಣೆಗೆ, ಕ್ಲೈಂಟ್ ಟ್ರೇಸಿಂಗ್ ಮಾಹಿತಿಯನ್ನು ಕಳುಹಿಸಿದರೆ ಒಟ್-ಕಸ್ಟಮ್-ಟ್ರೇಸಿಡ್ ಅಥವಾ ಒಟ್-ಕಸ್ಟಮ್-ಸ್ಪೇನಿಡ್ ಕಸ್ಟಮ್ ಹೆಡರ್‌ಗಳಲ್ಲಿ, ಈ ಫಿಲ್ಟರ್ ವಿನಂತಿಯನ್ನು ಪ್ರತಿಬಂಧಿಸುತ್ತದೆ, ಈ ಹೆಡರ್‌ಗಳನ್ನು ಹೊರತೆಗೆಯುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಮ್ಯಾಪ್ ಮಾಡಿದ ಡಯಾಗ್ನೋಸ್ಟಿಕ್ ಸಂದರ್ಭ (MDC) ಗೆ ಪ್ರಚಾರ ಮಾಡುತ್ತದೆ. MDC ಗೆ ಟ್ರೇಸ್ ಐಡಿಗಳನ್ನು ಸೇರಿಸುವ ಮೂಲಕ, ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಾಗ ರಚಿಸಲಾದ ಲಾಗ್‌ಗಳಲ್ಲಿ ಈ ಗುರುತಿಸುವಿಕೆಗಳು ಗೋಚರಿಸುತ್ತವೆ ಎಂದು ನಾವು ಖಚಿತಪಡಿಸುತ್ತೇವೆ.

MDCಯು SLF4J ಮತ್ತು Logback ನಂತಹ ಲಾಗಿಂಗ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳ ನಿರ್ಣಾಯಕ ಭಾಗವಾಗಿದೆ. ಪ್ರಸ್ತುತ ಥ್ರೆಡ್‌ಗಾಗಿ ಕಸ್ಟಮ್ ಟ್ರೇಸ್ ಐಡಿಗಳಂತಹ ಸಂದರ್ಭೋಚಿತ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಇದು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಮುಂತಾದ ಆಜ್ಞೆಗಳನ್ನು ಬಳಸುವುದು MDC.ಪುಟ್ ಮತ್ತು MDC. clear, ಲಾಗಿಂಗ್ ಸಿಸ್ಟಮ್ ಜಾಡಿನ ವಿವರಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಮತ್ತು ಏಕಕಾಲೀನ ವಿನಂತಿಗಳ ನಡುವೆ ಮಾಲಿನ್ಯವನ್ನು ತಪ್ಪಿಸುತ್ತದೆ ಎಂದು ನಾವು ಖಚಿತಪಡಿಸುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, ಕ್ಲೈಂಟ್ ಎರಡು `ot-custom-traceid` ಅನ್ನು `8f7ebd8a73f9a8f50e6a00a87a20952a` ಎಂದು ಕಳುಹಿಸಿದರೆ, ಈ ID ಅನ್ನು MDC ಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಲಾಗ್‌ಗಳಲ್ಲಿ ಸೇರಿಸಲಾಗುತ್ತದೆ, ಸ್ಥಿರವಾದ ಜಾಡಿನ ಮಾರ್ಗವನ್ನು ರಚಿಸುತ್ತದೆ.

ಮತ್ತೊಂದೆಡೆ, ಹೊರಹೋಗುವ HTTP ವಿನಂತಿಗಳಿಗಾಗಿ, RestTemplate ಇಂಟರ್ಸೆಪ್ಟರ್ ಪ್ರಮುಖ ಪಾತ್ರವನ್ನು ವಹಿಸುತ್ತದೆ. ಅನುಷ್ಠಾನಗೊಳಿಸುವ ಮೂಲಕ ClientHttpRequestInterceptor, ಹೊರಹೋಗುವ ವಿನಂತಿಗಳಿಗೆ ನಾವು ಅದೇ ಟ್ರೇಸ್ ಹೆಡರ್‌ಗಳನ್ನು (`ot-custom-traceid` ಮತ್ತು `ot-custom-spanid`) ಲಗತ್ತಿಸಬಹುದು. ಅಪ್ಲಿಕೇಶನ್ ಇತರ ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಳಿಗೆ ಕರೆ ಮಾಡಿದಾಗ ಜಾಡಿನ ನಿರಂತರತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುವುದನ್ನು ಇದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಸರ್ವರ್ ಟ್ರೇಸ್ ಐಡಿ `8f7ebd8a73f9a8f50e6a00a87a20952a` ನೊಂದಿಗೆ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದಾಗ, ಅದು ಈ ಐಡಿಯನ್ನು ಹೊರಹೋಗುವ ಹೆಡರ್‌ಗಳಿಗೆ ಲಗತ್ತಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಸೇವೆಗಳು ಟ್ರೇಸ್ ಅನ್ನು ಮನಬಂದಂತೆ ಗುರುತಿಸಬಹುದು ಮತ್ತು ಪ್ರಚಾರ ಮಾಡಬಹುದು.

ಅಂತಿಮವಾಗಿ, MockMvc ನೊಂದಿಗೆ ಬರೆಯಲಾದ ಘಟಕ ಪರೀಕ್ಷೆಗಳು HTTP ವಿನಂತಿಗಳನ್ನು ಅನುಕರಿಸುವ ಮೂಲಕ ಮತ್ತು ಹೆಡರ್ ಪ್ರಸರಣವನ್ನು ಪರಿಶೀಲಿಸುವ ಮೂಲಕ ಸಂಪೂರ್ಣ ಸೆಟಪ್ ಅನ್ನು ಮೌಲ್ಯೀಕರಿಸುತ್ತವೆ. ನೈಜ-ಪ್ರಪಂಚದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ, ಟ್ರೇಸ್ ಹೆಡರ್‌ಗಳನ್ನು ಸರಿಯಾಗಿ ನಿರ್ವಹಿಸಲಾಗಿದೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಪರೀಕ್ಷೆಯು ನಿರ್ಣಾಯಕವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಕಸ್ಟಮ್ ಹೆಡರ್‌ಗಳೊಂದಿಗೆ GET ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವ ಮೂಲಕ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಅಥವಾ ಲಾಗ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಮೂಲಕ, ಫಿಲ್ಟರ್ ಮತ್ತು ಇಂಟರ್‌ಸೆಪ್ಟರ್ ನಿರೀಕ್ಷೆಯಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಾವು ಖಚಿತಪಡಿಸಬಹುದು. ಈ ಸಮಗ್ರ ವಿಧಾನವು ಸ್ಪ್ರಿಂಗ್ ಕ್ಲೌಡ್ ಸ್ಲೀತ್‌ನಂತಹ ಪರಂಪರೆ ಅವಲಂಬನೆಗಳನ್ನು ಅವಲಂಬಿಸದೆ ಸವಾಲನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಅಂತಿಮವಾಗಿ, ಫಿಲ್ಟರ್‌ಗಳು, ಇಂಟರ್‌ಸೆಪ್ಟರ್‌ಗಳು ಮತ್ತು MDC ಗಳ ಸಂಯೋಜನೆಯು ಗ್ರಾಹಕರು ಕಸ್ಟಮ್ ಹೆಡರ್‌ಗಳನ್ನು ಬಳಸಿದಾಗಲೂ ಟ್ರೇಸ್ ನಿರಂತರತೆಯನ್ನು ಖಾತ್ರಿಗೊಳಿಸುತ್ತದೆ, ಇದು ಸಿಸ್ಟಮ್ ಅನ್ನು ದೃಢವಾಗಿ ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ಗಮನಿಸಬಹುದಾಗಿದೆ. 🌟

// 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;
    }
}

ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್ 3.4 ರಲ್ಲಿ ಓಪನ್ ಟೆಲಿಮೆಟ್ರಿಯೊಂದಿಗೆ ಕಸ್ಟಮ್ ಹೆಡರ್ ಟ್ರೇಸ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು

ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್ 3.4 ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, ಕಸ್ಟಮ್ ಹೆಡರ್‌ಗಳಿಂದ ಕುರುಹುಗಳನ್ನು ಪ್ರಚಾರ ಮಾಡುವ ಮತ್ತೊಂದು ಶಕ್ತಿಯುತ ವಿಧಾನವೆಂದರೆ ಸಂಯೋಜಿಸುವುದು ಓಪನ್ ಟೆಲಿಮೆಟ್ರಿ. ಓಪನ್ ಟೆಲಿಮೆಟ್ರಿ, ತೆರೆದ ಮೂಲ ವೀಕ್ಷಣಾ ಚೌಕಟ್ಟು, ಉಪಕರಣ, ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ಕುರುಹುಗಳನ್ನು ಮನಬಂದಂತೆ ರಫ್ತು ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಕಸ್ಟಮ್ ಹೆಡರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಟ್ರೇಸ್ ಸಂದರ್ಭವನ್ನು ಹೊರತೆಗೆಯಲು ಮತ್ತು ಇಂಜೆಕ್ಟ್ ಮಾಡಲು ಇದು ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ ಒಟ್-ಕಸ್ಟಮ್-ಟ್ರೇಸಿಡ್ ಮತ್ತು ಒಟ್-ಕಸ್ಟಮ್-ಸ್ಪೇನಿಡ್, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ. OpenTelemetry ನ TextMapPropagator ಅನ್ನು ನಿಯಂತ್ರಿಸುವ ಮೂಲಕ, ನೀವು ಪ್ರಮಾಣಿತವಲ್ಲದ ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ನಿಮ್ಮ ವೀಕ್ಷಣಾ ವ್ಯವಸ್ಥೆಯ ನಡುವಿನ ಅಂತರವನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.

ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್ 3.4 ರಲ್ಲಿ OpenTelemetry ಅನ್ನು ಬಳಸಲು, ಕಸ್ಟಮ್ ಹೆಡರ್‌ಗಳಿಂದ ಟ್ರೇಸಿಂಗ್ ಮಾಹಿತಿಯನ್ನು ಹೊರತೆಗೆಯಲು ಮತ್ತು ಅದನ್ನು ಪ್ರಸ್ತುತ ಜಾಡಿನ ಸಂದರ್ಭಕ್ಕೆ ಲಗತ್ತಿಸಲು ಕಸ್ಟಮ್ ಪ್ರಚಾರಕ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ನಿಮ್ಮ ಸರ್ವರ್ ಕ್ಲೈಂಟ್ ಎರಡರಿಂದ ಒಳಬರುವ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, OpenTelemetry ಕಸ್ಟಮ್ ಹೆಡರ್‌ಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡಬಹುದು ಮತ್ತು ಮೂಲ ಜಾಡಿನ ಸಂದರ್ಭವನ್ನು ಮರುನಿರ್ಮಿಸಬಹುದು. ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಸೇವೆಗಳು ಒಂದೇ ಟ್ರೇಸ್ ಐಡಿಗಳನ್ನು ನೋಡುವುದನ್ನು ಇದು ಖಚಿತಪಡಿಸುತ್ತದೆ, ಇದು ಅಂತ್ಯದಿಂದ ಅಂತ್ಯದ ಗೋಚರತೆಯನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಸ್ಪ್ರಿಂಗ್ ಕ್ಲೌಡ್ ಸ್ಲೀತ್ ನಂತಹ ಹಳೆಯ ಪರಿಹಾರಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿ, OpenTelemetry ಹಗುರವಾಗಿದೆ ಮತ್ತು ಆಧುನಿಕ ವೀಕ್ಷಣಾ ಮಾನದಂಡಗಳೊಂದಿಗೆ ಸರಿಹೊಂದಿಸುತ್ತದೆ.

ಮೈಕ್ರೋಮೀಟರ್ ನೊಂದಿಗೆ OpenTelemetry ನ ಪ್ರಚಾರಕವನ್ನು ಸಂಯೋಜಿಸುವ ಮೂಲಕ, ನೀವು ನಿಮ್ಮ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಉತ್ಕೃಷ್ಟಗೊಳಿಸಬಹುದು ಮತ್ತು ಜಾಡಿನ ಮಾಹಿತಿಯೊಂದಿಗೆ ಲಾಗಿಂಗ್ ಮಾಡಬಹುದು. ನಿಮ್ಮ ವೀಕ್ಷಣಾ ಸಾಧನದಲ್ಲಿ ಕ್ಲೈಂಟ್ ಒನ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ಟು ಎರಡರಿಂದಲೂ ಮನಬಂದಂತೆ ಬರುವ ವಿನಂತಿಗಳಿಗೆ ಕುರುಹುಗಳನ್ನು ನೋಡುವುದನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. OpenTelemetry ಸ್ವಯಂಚಾಲಿತವಾಗಿ Prometheus, Zipkin, ಅಥವಾ Jaeger ನೊಂದಿಗೆ ಏಕೀಕರಣವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, ಜಾಡಿನ ದೃಶ್ಯೀಕರಣವನ್ನು ಕೇಂದ್ರೀಕರಿಸಲು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಈ ವಿಧಾನವು ಕಸ್ಟಮ್ ಹೆಡರ್‌ಗಳು ಒಳಗೊಂಡಿದ್ದರೂ ಸಹ, ಯಾವುದೇ ಟ್ರೇಸ್ ಡೇಟಾ ಕಳೆದುಹೋಗುವುದಿಲ್ಲ ಮತ್ತು ಡೀಬಗ್ ಮಾಡುವುದು ಗಮನಾರ್ಹವಾಗಿ ಸುಲಭವಾಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. 🚀