Service Mesh : Telemetry (Jaeger) - 분산 추적, 헤더 확장

업스트림 요청

업스트림 pod 

업스트림 사이드카 -> child span을 생성

 

<-> 다운스트림 요청, 리턴되는 데이터 흐름 

 

전체 흐름 표시 = Trace

각각의 개별 타이밍 요소 = Span

 

컨테이너로부터 사이드카로 가는 요청을 추적

한 컨테이너에서 다른 컨테이너로 요청하면 그게 프록시를 거치니까 스팬이 두 배가 될 수 있음.

 

 

Service 선택->

어떤 식으로든 방문한 서비스의 모든 트레이스를 보여줌.

한 번 클릭하면 3개의 HTTP 요청이 시스템을 통과하게 됨.

이 사용자의 인터페이스 3개의 HTTP 요청들을 주게 됨... 이 서비스 안에서 3개... 정해놓은...

 

 

같은 서비스가 겹치는 이유 -> 프록시 있으니까~

 

 

이렇게 확장해서 보게되면 url로 city truck을 클릭해서 저래 됐구나를 알 수도 있는거셈

 

헤더를 확장시켜야만 동작한다!?

분산 추적을 작동시키려면 코드를 수정해야한다!?

 

아키텍처를 통과하는 요청 체인이 있다면, 분산 추적 메커니즘은 그 모든 요청이 하나의 트레이스를 위한 것이 되도록 해야함.

그런 요청들을 연관시켜야한다는 것.

그걸 하는 방법 => 반자동(semi-automatic)

 

guid:x-request-id

무작위 고유 식별 아이디

똑같은 x-request-id

모든 트레이스의 이 id가 똑같음

만일 요청의 request-id가 똑같으면 모두 하나의 스팬으로 그룹화 됨.

 

근데 이 id가 어디서 오냐?

istio가 자동생성한거임

 

만일 유입된 요청에 이 request-id가 없으면? 일단 없지 않을거임

프록시가. 타깃 포드 프록시를 호출할 때 자동으로 저 아이디라는 헤더를 추가하고 자동으로 그 guid를 생성하게 될거임.

 

자동으로 외부로 전송될 것 같지만 아님.?

what is required for distributed tracing with istio?

응용 프로그램, 코드를 확장시켜야됨.

trace context를.

 

직접 안하면 여러 개의 트레이스가 생길 것이고 각각에는 하나나 두 개의 스팬만 생길 거고 다 분산될거임. 

트레이스에 모든 스팬이 포함되길 원하면 guid가 같아야 함.

 

그 값을 외부로 가는, 컨테이너로 가는 요청에 전송해야 동일한 request-id를 얻게 됨.(새로 생성X)

아키텍처에 배포해야 할 모든 컨테이너에 이걸 배포해야됨.

그래야 하나로 통합된다~~

 

답변에서는 이스티오 사이드카,

즉 다른 말로 하자면 envoy 프록시에는 외부로 가는 요청을 그것을 유발한 내부로 가는 요청과 연관시키는 암묵적 방법이 없다고 나와 있습니다.

유입되는 id가 47인 요청이 있고, 만일 이 컨테이너가 약간의 처리를 하고 외부로 가는 요청을 전송하는 x-request-id 필드가 없다면 여기 있는 이 프록시는 유입되는 요청에 의해 이 요청이 유발되었다는 걸 알 수 있는 방법이 없음.

 

자동 헤더 확산이 없으면 이 모든 트레이싱 시스템의 유용성이 훨씬 떨어진다는 것