title: "Istio Distributed Tracing w/ OpenTelemetry"
description: "Istio의 distributed tracing 전반에 대해, 특히 OpenTelemetry 기반으로 논한다."
cleanUrl: /sw-engineer/istio-opentelemetry-tracing
ogImage: "<https://anyflower.notion.site/image/https%3A%2F%2Fprod-files-secure.s3.us-west-2.amazonaws.com%2F7570d2fc-66b1-4e23-bb3c-ff7b56842b0d%2F47b80152-f609-406e-ad00-93f7e29c5647%2FUntitled.png?table=block&id=0ca8847b-6804-4a76-9226-14c23514593f&spaceId=7570d2fc-66b1-4e23-bb3c-ff7b56842b0d&width=1420&userId=&cache=v2>"
floatFirstTOC: right

Introduction

Istio의 distributed tracing 전반에 대해, 특히 OpenTelemetry 기반으로 논한다.

Summary

Istio는 distributed tracing의 핵심인 trace ID와 span ID를 생성 및 관리하여 header로 제공한다.
다만 Trace propagation은 application에서 수행해야 한다. 나머지는 Istio가 알아서 한다.
Istio는 OpenTelemetry가 채택한 W3C Trace Context를 지원한다. 그러나 default는 B3 propagation 이므로 별도 설정이 필요하다.

Istio 기반 distributed tracing 구조

Distributed tracing의 목적은 특정 request에 대한 관련 component 전체의 상태를 파악하는 것이다. 이를 Istio가 어떻게 이루는지 아래 3개의 components로 이루어진 transaction 예를 통해 설명한다.

Untitled

gateway가 dockebi로 request 보내는 것으로 시작해 dockebi-storage를 거쳐 최종 response를 받는 간단한 구조이다. 화살표 번호는 traffic 순서를 나타내고 ingress, egress는 해당 component 관점에서의 Istio proxy를 의미한다. 참고로, dockebi component에는 마치 Istio proxy가 ingress / egress의 두 개인 양 오해하기 쉬운데 이는 설명 편의 상 나눈 것으로, 단일 Istio proxy가 ingress / egress traffic 모두를 처리한다.

아래는 위 구조 하에서의 특정 trace에 대한 Grafana distributed tracing 뷰로, tracing backend로는 Jaeger를 사용하였다.

Grafana에서의 distributed tracing 뷰. Jaeger도 완전히 동일한 구성의 뷰를 제공한다.

위 그림의 붉은색, 분홍색, 초록색 막대 각각은 component에 대한 각 ingress / egress traffic의 시작과 끝 시간 및 관련 정보, 즉 span을 의미한다. 위에서부터 아래로 gateway (egress) → dockebi (ingress) → dockebi (egress) → dockebi-storage (ingress) 가 나열되어 있다. 또한 span을 클릭하면 span 상세 정보가 나타나는데, 위에서는 gateway (egress) 의 상세 정보가 보인다.

span에는 parent span, 즉 자신 span을 생성한 span이 있기 마련인데, 위 그림 상에서는 자신의 바로 위에 위치한 span이 parent span이 된다. trace는 특정 request에 대한 end to end 여정 전체를 의미하여 parent - child 관계로 연결된 span의 모음으로 구성된다. 즉 모든 span은 특정 trace에 속한다.

Istio는 이들 trace와 span에 대한 정보를 자동 생성, 관리한다. 각 component에서의 매 request마다 span을 생성하고 전파된(propagation) trace ID가 없으면 이를 새로 생성하여 해당 span을 엮는다. 또한 span 각각에 대해 시작과 끝을 자동으로 매핑한다. 그리고 이들에 대한 ID, 즉 trace ID / span ID는 traceparent header를 통해 app에 전달한다. 단, trace ID의 전파, 즉 span의 parent - child 관계 설정은 Istio가 처리 못하여 application level에서 처리해야 하는데, 이어지는 섹션은 이에 대한 상세이다. 그 이후로 traceparent header 상세를 다룬다.

<aside> 💡 Distributed tracing 기능 실제 제공 주체는 Envoy Istio가 제공하는 대부분의 기능이 그렇지만, distributed tracing 기능 역시 사실 Envoy가 제공한다. Istio는 이에 대한 wrapper일 뿐이다.

</aside>

Trace propagation

trace ID의 전파, 즉 span의 parent - child 관계를 설정 못하면 각 component의 상태가 어느 request에 해당하는지를 알 수가 없기에 distributed tracing이 불가능하다. 아쉽게도 Istio는 이를 처리 못하기에 application level의 변경이 필요하다(그러나 간단하다). 아래 링크는 이에 대한 Istio의 공식 설명이다.