Spring 모니터링 Part 3.

날짜:

테스트와 운영 점검 기준 정리

관측성은 설정이 아니라 확인 절차다

로그와 tracing 설정을 추가해도 실제 요청에서 값이 이어지지 않으면 운영 장애에는 도움이 되지 않는다. 마지막 단계에서는 테스트, 비동기 경계, 운영 점검 항목을 묶어 본다. 목표는 "로그가 나온다"가 아니라 같은 요청의 requestId, traceId, 주요 span을 반복해서 찾을 수 있는 상태를 만드는 것이다.

테스트에서 로그 필드를 확인한다

@SpringBootTest
@AutoConfigureMockMvc
@ExtendWith(OutputCaptureExtension.class)
class ObservabilityLogTest {
    @Autowired MockMvc mvc;

    @Test
    void requestIdAppearsInLog(CapturedOutput output) throws Exception {
        mvc.perform(get("/orders/1")
                .header("X-Request-Id", "req-test-1"))
                .andExpect(status().isOk());

        assertThat(output.getOut()).contains("req-test-1");
    }
}

이 테스트는 수집기까지 검증하지는 않지만 애플리케이션 경계에서 MDC 값이 로그로 나오는지 확인한다. 구조화 로그를 파일로 남기는 환경이라면 JSON 파서로 requestId 필드를 읽는 테스트를 추가할 수 있다.

스레드가 바뀌는 구간을 따로 본다

@Async나 직접 만든 executor를 사용하면 요청 스레드의 관측 컨텍스트가 작업 스레드로 자동 복원되지 않을 수 있다. Spring Boot 문서는 이런 경우 ContextPropagatingTaskDecorator를 executor에 연결하라고 안내한다.

@Configuration
class AsyncTraceConfig {
    @Bean
    TaskExecutor applicationTaskExecutor(
            ContextPropagatingTaskDecorator decorator) {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setTaskDecorator(decorator);
        executor.setThreadNamePrefix("app-async-");
        return executor;
    }
}

비동기 로그에 traceId가 비어 있다면 이 지점부터 확인한다. 단순히 스레드 이름만 맞는지 보는 것이 아니라, 요청 안에서 발생한 비동기 작업이 같은 trace에 붙는지 tracing backend와 로그를 같이 본다.

운영 기준을 짧게 고정한다

운영 체크리스트는 길 필요가 없다. 배포 전에는 health endpoint, 대표 API 한 개, 외부 호출 한 개를 실행하고 로그와 trace 화면에서 같은 식별자를 찾는다. 배포 후에는 샘플링 비율, 로그 누락률, 수집 지연, 개인정보 필드 유입 여부를 본다.

문제가 생기면 먼저 요청 ID로 로그를 좁히고, trace 화면에서 느린 span을 찾은 뒤, 해당 구간의 예외 로그를 확인한다. 이 순서가 반복 가능하면 관측성 구성은 문서 속 설정이 아니라 장애 대응 절차가 된다.

댓글

댓글 쓰기