2.jaeger

jaeger는 분산 추적 framework 즉, 시스템에 전송하는 단일 요청을 추적할 수 있음을 의미한다. 문제가 생기거나 탐구하고 싶은 단일 요청에 대해서 요청의 이동경로에 관해 상세한 정보를 얻을 수 있는 것이다.

참고로, istio에 포함된 zipkin도 jaeger와 동일한 분산 추적 시스템이다. 보통 1개의 서비스로 이루어진데 반해 현재 클러스터에는 분산추적과 관련된 여러 개의 service가 존재한다. 특히 jaeger의 UI에 접근하기 위해서는 tracing service의 port로 접속해야한다.

jaeger의 UI는 다음과 같으며, 왼쪽 맨 위에서 service 1개를 선택하여 Find Traces를 클릭하면 다양한 trace들을 관찰할 수 있다.

정확히 trace란 전체 요청이 시스템에 있는 여러 microservice를 통과하는 과정을 추적하는 것을 의미하며, span은 각각의 개별 타이밍 요소를 의미합니다. 예를들어 1개의 trace에서 통과하는 microserivce가 3개가 된다면 총 span은 3개가 되며, 가장 긴 span이 전체 trace의 통과 시간이 된다. (참고로, sidecar proxy를 지나게 되어 span이 증가할 수 있음에 유의해야한다.)

해당 trace에 들어가 각 span의 세부사항에서 http method, url을 참고한다면 마이크로서비스를 파악하는데 큰 도움이 될 수 있을 것 같다.

강의를 추가로 듣다보니까, 각 요청 즉, span들이 동일한 trace에 속하는지 파악하기 위해 사용하는 정보는 span의 tag 세부사항의 guid:x-request-id 값을 이용한다. 문제는 이 헤더 값이 istio system에서 직접해주는게 아니라, 본인이 사용하는 microservice의 모든 파일에서 해당 헤더 작업을 해줘야 이 분산 추적을 사용할 수 있다는 것이다…
요청이 proxy에 도착할 때마다 proxy는 새로운 guid:x-request-id 값을 생성하는데, 이 요청이 다음 service의 proxy에 들어갔을 때 헤더 작업이 되어있지 않으면 헤더가 없는 줄 알고 새로운 x-request-id를 생성하기 때문에 모든 span이 개별 trace로 나타나기 때문에 소용이 없어진다. 다양한 헤더에 대한 정보는 istio의 distributed tracing 문서에 가면 찾아볼 수 있다.

강의 내에서는 Feign이라는 REST 호출을 할 수 있게 해주는 라이브러리를 사용해서 구현해 놓은 것은 참고만하자.

istio를 사용하려는게 사용자의 응용프로그램을 변경하지 않고 사용할 수 있다는 점인데 distributed tracing 부분에서는 예외기 때문에 아마 해당 사용하지 않을까 싶다…. 혹시나 내가 aiml에 적용했을 때 생겼던 헤더의 오류문제가 아마 여기서 발생한것 같다… 기억하기 위해서 메모해둔다…