[Istio] Telemetry (kiali, jaeger)

DevOps

[Istio] Telemetry (kiali, jaeger)

KIM DEON 2024. 1. 14. 18:05

이전 글을 참고하면 좋습니다. [DevOps] - Istio Overview

Kiali 주요 기능

fleetman-api-gateway -> fleetman-staff-service 최근 1분간 트래픽이 없었다.

kiali의 service graph는 두 service 간에 트래픽이 발생하지 않으면 회색 선 처리가 되며, 일정 시간이 지나면 아예 선이 사라진다. 또한 요청이 발생하자마자 트래픽을 바로 실시간으로 보여줄 순 없기 때문에, 특정 서비스가 사라졌다고 생각되면 요청을 전송해서 시스템을 시험하거나 창을 변경(기간 및 새로고침 텀)하며 테스트해야한다.

graph type을 Workload graph로 확인하면 서비스 및 워크로드 사이의 response time을 확인할 수 있다.

Disply 옵션을 선택하면 트래픽의 흐름을 애니메이션으로 보여준다. payload의 크기 및 트래픽의 양에 따라 아이콘이 달라지므로 유용할 수 있다.

Kiali 동적 트래픽 라우팅

특정 서비스에 이슈가 생겨, 해당 서비스로 이동하는 모든 트래픽을 끊고 싶을 수 있다. 이스티오는 VirtualService 객체를 통해 트래픽 관리 기능을 제공한다.

service graph에서 특정 service를 우클릭하면 디테일을 볼 수 있다.

서비스의 디테일 화면 / VirtualSerivce가 적용도면, 아이콘이 삼각형으로 바뀐다.

kiali 를 통해서도 트래픽 중단이 가능하다. 서비스의 디테일 창으로 들어서 Suspend Traffic 을 누르면 된다. 해당 동작은 VirtualService 객체를 만든다.

# kubectl get virtualservices
$ kubectl get vs
default     fleetman-staff-service                  ["fleetman-staff-service.default.svc.cluster.local"]   21s

kiali에서도 적용된 yaml을 확인할 수 있다.

삭제도 가능하다.

Delete All Traffic Routing은 서비스에 적용된 VirtualService와 DestinationRule을 삭제한다.

Distributed Tracing Overview

kiali의 UI는 아주 유용하지만, 사실 우리는 개별 요청의 디테일한 정보는 kiali를 통해 확인할 수 없다. 분산 추적 프레임워크인 jaeger를 사용하면 우리가 시스템에 전송하는 단일 요청을 추적할 수 있다. 요청이 유발하는 이벤트들을 그래프로 볼 수도 있다.

요청이 시스템에 있는 여러 마이크로서비스를 통과하는 과정을 추적한 것을 trace 라고 부른다. 그리고 각각의 개별 타이밍 요소를 span 이라고 한다.

Webapp 서비스 span이 만약 10s 라고 치면,Webapp 서비스가 10s 동안 요청을 처리한 것이 아니라, 다른 ms 과의 통신을 모두 거쳐 응답을 돌려받은 시간을 포함한다고 보면 된다.

이렇게 보면 3개의 서비스가 존재하기 때문에 3개의 span이 있을 것 같지만, 실제로는 더 많다. 우리는 pod안에 모두 proxy가 존재하고, 컨테이너로부터 사이드카로 가는 요청도 모두 추적하기 때문이다. 체인에 있는 마지막 pod을 제외하고는 span이 두 배일 것이다

Jaeger UI

jaeger가 추척한 trace를 하나 보면, 마지막 서비스외에 서비스가 두번 씩 나타나는 것을 볼 수 있다. pod 내의 istio proxy로 가는 모든 요청을 추적하고 있다.

노란 부분이 proxy가 다른 ms로 요청을 보내고 받는데 소요된 시간이라고 볼 수 있다.

span의 detail 화면을 보면 유용한 정보가 많다. 위 span은 webapp 서비스가 fleetman-api-gateway 서비스로 http 요청을 보내는 span이다. inbound와 outbound 트래픽을 잘 구분하여 정보를 파악하도록 하자.

Propagate Headers

https://istio.io/latest/about/faq/distributed-tracing/

k8s 리소스를 수정하지 않고도 istio의 기능을 훌륭히 사용할 수 있다. 하지만 위와 같이 분산 추적을 사용하려면 수정이 필요하다.

하나의 요청으로부터 야기된 span들은 x-request-id 필드의 값이 모두 동일해야한다. 그렇지 않으면 동일 요청에 대해 하나의 trace에 여러개의 span들이 적절히 묶일 수 었다.

이 x-request-id 값은 기본적으로 istio proxy 자동으로 생성한다. pod내의 proxy의 로직 중 하나가 유입된 요청에 x-request-id가 없으면 다음 타겟이 되는 pod proxy를 호출할 때 자동으로 x-request-id 헤더를 추가한다.

문제는 타겟 컨테이너는 x-request-id 헤더와 함께 요청을 받지만, 다음 proxy로 요청을 보낼 때는 같은 해당 x-request-id 값을 보내줘야 동일 요청에 대해 같은 x-request-id 값을 유지할 수 있다. x-request-id를 보내주지않으면, 다음 proxy가 x-request-id 헤더가 값이 없으니 다른 값으로 채울 것이고, 같은 요청에 대해 여러 trace가 생성되게 된다.

istio는 왜 이걸 istio가 해주기 어려운지 문서에도 작성해놓았다. 참고해두자.

https://istio.io/latest/about/faq/distributed-tracing/

어플리케이션에 헤더를 추가하기 위해서, 즉 헤더를 확산시키기 위한 방법은 istio 문서에서 sample과 함꼐 확인할 수 있다.

사용하는 rest api 라이브러리에 자동 헤더확산 기능이 있다면(request의 헤더를 그대로 보내는 기능) 활용하도록 하자. (ex. spring boots의 Feign 라이브러리는 자동 헤더 확산이 가능하다.)

Grafana

istio 시스템을 배포하면 grafana가 함께 배포된다.

istio의 각종 dashboard가 내장된 채 배포되는데, 이 중 Istio Service Dashboard와 Istio Workload Dashboard는 kiali와 비슷한 역할을 하며, 나머지는 istio 자체에 대한 모니터링 dashboard이다. istio의 성능에 문제가 있는 것이 아니라면, Service Dashboard 및 Workload Dashboard가 유용할 것이다.

또한 Istio Mesh Dashboard는 우리의 서비스 아키텍처에서 무슨 일이 일어나고 있는지 전체적으로 파악하기 좋은 데이터를 보여준다.

참고: https://github.com/DickChesterwood/istio-fleetman/tree/master/_course_files