Distributed Tracing in LINE Taiwan — 大規模分散式追蹤的實踐與挑戰 John Lin Site Reliability Engineer, LINE Taiwan @ COSCUP 2024 X KCD Taipei

Slides Download: https://tinyurl.com/dt-in-line 2

About Me • John Lin, Site Reliability Engineer at LINE Taiwan • Previously at Tencent • Kubernetes, Observability & Networking • Follow me on X: @johnlin__ • Less work – More Tennis! ! 3

Outline • 分散式追蹤的概述 • 基本概念、如何工作、開源專案及技術堆疊 • LINE Taiwan 的分散式追蹤系統 • 背景及技術發展、系統架構的演進 • 挑戰與應對策略 • 數據量和性能、組織和協作 • 未來展望 • 新技術和趨勢 4

分散式追蹤的概述 5

基本概念 • 分散式追蹤(Distributed Tracing)是資料請求 在分散式系統上流動時加以觀察的實踐 • 舉例：⼀個典型的 E-Commerce 後端微服務 架構 • 具有多個⼩型的獨⽴元件 • 元件彼此間透過 RPC/REST 通訊和交換資 料 • 採⽤分散式追蹤技術： • 提供開發⼈員在不同微服務之間追蹤（視覺 ⽅式） • 提供疑難排解錯誤或修復效能問題的能⼒ 6

基本概念 • 分散式鏈路追蹤技術源於 Google Research 發表的論⽂ Dapper 1 • Google 透過採⽤ Distributed Systems Tracing 旨在解決： • 於不同團隊、不同語⾔、不同元件及佈署在不同節點上，所帶 來的排錯複雜性 1 Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Research, 2010 7

如何工作 • ⽤⼾發起⼀次請求到 A 經5個不同⼩型 的獨⽴元件 • 前端、2個中間層、2個後端 • 對於請求 X，分散式跟蹤的實現 • 在每⼀個節點上，每⼀次發送和接收 時有收集 • 跟蹤識別標籤(message identifiers) • 時間戳(timestamped events) 8

分散式追蹤系統的需求 • 性能低損耗：對性能敏感的硬⽤不能產 ⽣損耗 • 對應⽤透明：以⾮侵⼊的⽅式實現追蹤 （盡可能對業務源碼低侵⼊） • 追蹤數據可視化：為了讓開發者能夠更 快定位問題，將這些追蹤鏈路以視覺⽅ 式呈現 • 因果關係 • 時間關係 9

開源專案及技術堆疊 • X(formerly Twitter) Open Source Zipkin in 2012: • Distributed Systems Tracing with Zipkin • Naver Open Source PinPoint in 2015 • Uber Open Source Jaeger in 2017: • Evolving Distributed Tracing at Uber Engineering • Elastic N.V. Open Source Elastic APM in 2018 10

開源專案及技術堆疊 • 開源規範標準及框架 SDK • OpenTracing 是分散式追蹤的⼀種規範標準，原為 CNCF 下的⼀個專 案之⼀，同時也提供主流程式語⾔的開源框架 • 開源框架 SDK • OpenCensus 是⼀個⽤於分散式追蹤和監控的開源框架，提供多種程 式語⾔的 instrumentation frameworks • 2019, OpenTracing 和 OpenCensus 合併成為⼀個新的 CNCF 項⽬ OpenTelemetry 繼承並擴展了原專案，提供了⼀套統⼀的 API 和 SDK 11

LINE Taiwan 的分散式追蹤系統 12

背景及技術發展 2020 前團隊內部採⽤ Distributed Tracing 情況 • 因 Zipkin 發展早2012且相對成熟 • 團隊內部 Java 系大部分都會選擇採⽤ Zipkin • 有極少部分團隊採⽤ PinPoint • Naver 技術⽀援 • 大部分團隊無採⽤ Distributed Tracing 2012 Twitter: Distributed Systems Tracing with Zipkin 13

背景及技術發展 2020 開始著⼿採⽤當時 CNCF 已畢業的 Jaeger 作為 Distributed Tracing 平台 • 初期導⼊包含 • jaeger-agent/jaeger-collector • jaeger 的 tracing backend • 協助開發團隊完成 jaeger-client instrumentation • Manual instrumentation • Automatic instrumentation 14

背景及技術發展 • 2021 關注到 OpenTelemetry 成為 CNCF 的孵化中的項⽬，同時 Grafana 發表了 Grafana Tempo 1.0 • 開始導⼊ Opentelemetry • Opentelemetry collector 取代 • jaeger agent (sidecar) • jaeger collectors • 協助專案團隊採⽤ Opentelemetry instrumentation libraries 15

背景及技術發展 • Grafana 發表了 Grafana Tempo 1.0 • Distributed Tracing backend 改採⽤ Grafana Tempo • 由於 Grafana Tempo ⽀援各種 Opensource Tracing format • 從 Jaeger tracing backend 正式轉 為 Grafana Tempo 16

系統架構的演進 初期 (2020) 採⽤ Jaeger 作為 Distributed Tracing 系統架構圖 • 挑戰⼀：需⽀援多個團隊的 Kubernetes Cluster (數⼗個 Clusters 以上) • 拆分寫⼊及讀取元件到不同 Clusters • 挑戰⼆：sidecar 模式，當需要調整參 數時涉及應⽤容器重啟 • ⽀援 collector 收應⽤送出的 spans 17

系統架構的演進 針對 sidecar 模式的改進作法 • 架構改進：接收 spans 的作法，⽀援 collector 收應⽤送出的 spans • jaeger collector 在不同環境下攜帶不 同標籤(tag) e.g. cluster=mycluster, env=beta 18

系統架構的演進 針對 sidecar 模式的改進作法 • 架構改進：接收 spans 的作法，⽀援 collector 收應⽤送出的 spans • jaeger collector 在不同環境下攜帶不同 標籤(tag) e.g. cluster=mycluster, env=beta 現象觀察 • sidecar 模式的確不太受應⽤開發的歡迎 • Spans 量大的時候 collector buffer 過 載 19

系統架構的演進 2021 改採⽤ Grafana Tempo 作為 Distributed Tracing 系統架構圖 • OpenTelemetry 在這個階段同時⼀起採 ⽤ • 為⽀援⽇漸增加的 spans 數量，採⽤ Kafka 作為寫⼊的緩衝 • 為過去的技術做相容包含⽀援 Jaeger, Zipkin, OpenTelemetry Protocol(OTLP)格式 20

系統架構的演進 採⽤ OpenTelemetry collector 後的改變 • 採⽤ opentelemetry-collector-contrib 社群貢獻的 collector • 與供應商無綁定 (vendor agnostic) • 有需求可⾃⾏開發 receiver, processor, exporter 21

挑戰與應對策略 22

數據量和性能 • 約 50 Kubernetes Clusters 上，不同環境、不同團隊 合計的 span rate • Tempo 處理及消化平均 RPS 約 200K 左右 spans • 三種格式⽬前都接受，OTLP 為⽬前為團隊主流及建 議的格式, Zipkin/Jaeger 為較早期的採⽤現已不建議 23

⽬前挑戰 • Span rate 會隨著活動事件有流量⾼峰 • 採樣策略的引⼊(tail-based sampling): 可控的費⽤、專注感興趣 的 traces、過濾雜訊 • 前端 spans 收集串連後端 spans 完成 ⼀個完整的 end-to-end 鏈路 • 採⽤ Grafana faro-web-sdk 及 Grafana Alloy Eric Huang Eric Huang Grafana Alloy 最佳實踐：多租⼾設計、性能優化與端到端追蹤 24

⽬前挑戰 • 多租⼾管理並未帶來好處：團隊服務間的系統調⽤鏈中斷 • 未來將改合併租⼾⽅式，以利團隊服務間追蹤查詢 • Instrumentation 的導⼊工作 • Auto-instrumentation: 需要函式庫及框架上的⽀援 • Manual instrumentation: 對現存 codebase 侵⼊性大，開發團隊接受意願度較 低 • OpenTelemetry Protocol: OTLP/gRPC 在 Kubernetes Service 的負載均衡效能差 • 引⼊ L7-Aware LB 例如 Envoy 做 HTTP/2的負載均衡 25

未來展望 26

新技術和趨勢 • 引⼊ eBPF 技術作為無侵⼊性的可觀測 性工具 • Grafana Beyla • Service Mesh but NOT Service mess Kelsey Hightower • Istio Serice Mesh • Cilium Service Mesh Kelsey Hightower 1. the result of spending more compute resources than your actual business logic dynamically generating and distributing Envoy proxy configs and TLS certificates. 27

新技術和趨勢 • 引⼊ eBPF 技術作為無侵⼊性的可觀測 性工具 • Grafana Beyla • Service Mesh but NOT Service mess Kelsey Hightower • Istio Serice Mesh • Cilium Service Mesh Kelsey Hightower 1. the result of spending more compute resources than your actual business logic dynamically generating and distributing Envoy proxy configs and TLS certificates. 28

Thank You