개요

분산 시스템에서 요청(로그) 추적을 위해 Spring Cloud Sleuth와 Zipkin을 사용해왔다.
하지만 Spring Boot 3버전부터는 Spring Cloud Sleuth의 지원이 중단되고 Micrometer Tracing으로 이전되었다.
logback을 통해 로그 파일을 생성하고 있는 현재 프로젝트에서 Zipkin 활용 시 얼마나 유용하게 사용할 수 있을지 한번 적용해보기로 했다.

Micrometer Tracing, Zipkin

Zipkin 설치

docker run -d -p 9411:9411 openzipkin/zipkin

우선 로컬환경에서 docker로 zipkin을 설치해줬다.
이후 아래 경로로 접속하면 대쉬보드에 접근할 수 있다.
http://localhost:9411/zipkin/

프로젝트 설정 수정

implementation 'io.micrometer:micrometer-tracing-bridge-brave'
implementation 'io.zipkin.reporter2:zipkin-reporter-brave'

위와 같이 의존성을 추가하면 로그에 trace id와 span id를 출력하게 된다.
이 id를 가지고 Zipkin에서 요청의 흐름을 확인 하고 검색할 수 있다.

하지만 현재 logback 설정을 해놓은 상태라 곧바로 로그에 뜨진 않았다.

logback 설정 파일 수정

<pattern>[%d{HH:mm:ss.SSSXXX}] [%level] [%X{traceId}] [%X{spanId}] [%thread] [%logger{36}] - %msg%n</pattern>

기존에 작성해둔 logback-spring.xml 파일에서 traceId, spanId를 추가로 출력하도록 xml을 수정하였다.

%X로 시작하는 traceId, spanId에 각각 출력 된다. 이 외에도 제공되는 트레이싱 정보가 있으니 활용해보면 좋을 것 같다.

참고

• https://easywritten.com/post/using-spring-boot-3-with-zipkin/

Gateway Filter 에러 해결

그렇게 모듈마다 설정을 추가해주었는데 Gateway Filter에서는 해당 로그가 출력되지 않는 것을 확인하였다.
다른 모듈과는 달리 Reactive 환경에서 동작하여 트레이싱이 적용되지 않는 것으로 생각하여 해결방법을 찾아보았다.

참고

• https://velog.io/@dbghwns11/Spring-Cloud-Gateway-Filter%EC%97%90%EC%84%9C-Zipkin-%EC%B6%94%EC%A0%81%EC%9D%B4-%EB%90%98%EC%A7%80-%EC%95%8A%EB%8A%94-%EB%AC%B8%EC%A0%9C-%ED%95%B4%EA%B2%B0
• https://stackoverflow.com/questions/75221864/how-to-get-trace-id-in-spring-cloud-gateway-using-micrometer-brave

위 Stack Overflow 내용처럼 main class에 아래 코드를 추가하니 정상적으로 로그를 출력하였다.

Hooks.enableAutomaticContextPropagation();

컨텍스트를 적절히 전파할 수 있도록 설정하는 코드이다.

Reactive 환경에서는 기본적으로 논블로킹과 스레드 전환이 자주 발생하기 때문에, 기존의 스레드 로컬(ThreadLocal)을 기반으로 한 컨텍스트 전파 방식이 제대로 동작하지 않아 이와 같은 현상이 발생하였다는 것을 알았다.

이제 이미지와 같이 요청을 추적할 수가 있다.

ELK

아래 글을 참고하여 ELK를 설치 해주었다. (설치하는 과정은 생략)
https://xodns.tistory.com/115

이런식으로 localhost에서 kibana를 통해 index 생성까지 완료 하였다.

생성 된 index를 discover에서 보기 위해서 index pattern을 생성 해줘야한다.

https://dgjinsu.tistory.com/34

위 링크에서 설명해주고 있지만 8.17.0 버전에서는 해당 메뉴가 보이지 않아 좀 헤맸다.

StackManagement > Kibana - Data View 에서 생성할 수가 있다.

마치며

Zipkin의 경우 다소 단촐한 대쉬보드 구성이지만 필요한 기능을 제공해주고 있었다. 처음에는 ELK 스택과 비교하여 사용하는 것으로 생각하였지만 로그 분석에 초점이 맞춰진 ELK 스택에 반해 분산 시스템의 요청(호출) 시간 추적 기능이 주요 기능으로 보여졌다.
tracdId로 요청을 추적하여 실행시간을 확인 할 수 있는 기능은 실제 운영되는 서비스에서 얼마나 유용하게 활용되는지 궁금증이 생겼다.

ELK 스택을 통한 로그 분석이 가능하도록 세팅해보았다.
현재는 로그 파일의 모든 내용을 Discover에서 보여주고 있고 원하는 키워드로 검색을 할 수 있는 정도이다.
관련해서 사용할 수 있는 기능에 대해 알아보고 활용해보면 좋을 것 같다.
그리고 filebeat를 함께 사용하여 로그 수집과 전송에서 최적화 할 수도 있다고 하여 현재는 ELK 스택만 활용하였지만 추후 적용해보면 좋을 것 같다.