建構 Netflix 分布式追蹤（tracing）體系
收錄于話題
#最近文章
5個
“為什麼我的手機不能播放 Tiger King？”
— 一位 Twitter 網友留言
這是 Netflix on-call 工程師面臨問題的一個例子：解決使用者碰到的各種問題。排除這種分布式系統的故障非常困難。調查視訊流故障需要檢查使用者賬戶的所有方面。在上一篇博文(1)中介紹了 Edgar，我們的流 sesion 故障排除工具。本文主要看我們是如何設計 Edgar 的追蹤 (tracing) 基礎設施。
(1) https://netflixtechblog.com/edgar-solving-mysteries-faster-with-observability-e1a76302c71f
分布式跟蹤：提供大規模服務中故障排查的上下文
在使用 Edgar 之前，工程師必須從 Netflix 的各種微服務中篩選出大量的中繼資料和日志，以了解我們任何使用者所經曆的特定流媒體故障。重建流 session 是一個繁瑣而耗時的過程，其中涉及到追蹤 Netflix 應用、CDN 網絡和後端微服務之間的所有互動（請求）。
這個過程從手動拉取作 session 的使用者賬戶資訊開始，并将所有的拼圖碎片放在一起，希望由此産生的全景能夠幫助解決使用者問題。是以需要通過分布式請求追蹤系統來提高生産力。
如果我們為每個流 session 提供一個ID，那麼分布式追蹤就可以通過提供服務拓撲、重試和錯誤标簽以及所有服務調用的延遲測量來輕松重建會話失敗。我們還可以通過将相關的跟蹤與賬戶中繼資料和服務日志結合起來，獲得有關流 session 的上下文資訊。這種需求促使我們建立了 Edgar：一個分布式跟蹤基礎設施以及使用者體驗。
Edgar: a distributed tracing infrastructure and user experience.
圖 1. 通過 Edgar 排查一個會話
4 年前，當開始建構 Edgar 時，能夠滿足我們需求的開源分布式追蹤系統非常少。我們的政策是，在開源 trace 庫成熟之前，使用 Netflix 專用工具來收集基于 Java 的流媒體服務的 trace 資訊。
到 2017 年，Open-Tracing (1) 和 Open-Zipkin (2) 等開源項目已經足夠成熟，可以在 Netflix 的混合運作環境中使用。我們選擇了 Open-Zipkin。因為它能與我們基于 Spring Boot 的 Java 運作時環境有更好的內建。
我們使用 Mantis (3) 來處理收集到的資料，使用 Cassandra 來存儲資料。分布式跟蹤基礎設施分為三個部分：跟蹤工具庫、 流式處理和存儲。從各種微服務收集到的 trace 資料以流處理的方式進入資料存儲中。下面的章節描述了建構這些元件的曆程。
(1) https://opentracing.io/
(2) https://github.com/openzipkin
(3) https://netflixtechblog.com/open-sourcing-mantis-a-platform-for-building-cost-effective-realtime-operations-focused-5b8ff387813a
跟蹤 Instrumentation：它将如何影響我們的服務？
這是我們工程團隊在內建 tracer 庫時提到的第一個問題。這是一個重要的問題，因為 tracer 庫攔截了流經關鍵任務流服務的所有請求。對于 polyglot 運作時，安全內建和部署 tracer 庫是我們的首要任務。我們了解工程師的運維負擔，并專注于在運作時環境中提供高效的跟蹤庫內建，并赢得了工程師的信任。
分布式跟蹤依賴于為本地程序間調用（IPC）和用戶端調用遠端微服務的任何任意請求傳遞的上下文。傳遞請求上下文，可以捕獲運作時微服務之間調用的因果關系。
我們采用了 Open-Zipkin 的基于 B3 HTTP (1) 頭的上下文傳播機制。我們確定在各種內建的 Java 和 Node 運作時環境中，微服務之間正确傳遞了上下文傳標頭，這些環境既包括具有傳統代碼庫的舊環境，也包括 Spring Boot 等新環境。
在面對 Python、NodeJS 和 Ruby on Rails 等環境的跟蹤庫時，執行我們文化中的自由與責任原則 (2) ，這些環境不屬于內建的範圍，我們松耦合但高内聚的工程團隊，可以自由選擇适合其運作時環境的跟蹤庫，并有責任確定正确的上下文傳播和網絡調用攔截器的內建。
(1) https://github.com/openzipkin/b3-propagation
(2) https://jobs.netflix.com/culture
我們的運作時環境內建注入了基礎設施标簽，如服務名稱、自動伸縮組（ASG）和容器執行個體辨別符。Edgar 使用這種基礎設施标簽模式來查詢和加入帶有日志資料的 trace 資訊，以便對流 session 進行故障排除。
此外，由于标簽的一緻性，在 Edgar 中為不同的監控和部署系統提供深度連結變得很容易。在運作時環境內建到位後，我們必須設定一個合适的 trace 資料采樣政策，以建構故障診斷功能。
流處理：采樣，還是不采樣？
這是我們在建構基礎設施時考慮的最重要的問題，因為資料采樣政策決定了記錄、傳輸和存儲的 trace 數量。寬松的跟蹤資料采樣政策，會在每個服務容器中産生大量的跟蹤資料，并且會導緻流服務的性能下降，因為跟蹤庫會消耗更多的 CPU、記憶體和網絡資源。
寬松的采樣政策的另一個影響是，需要可擴充的流處理和存儲基礎設施來處理增加的資料量。
大量取樣的跟蹤資料集對于故障診斷來說并不可靠，因為無法保證你想要的請求就在收集的樣本中。我們需要一種周到的方法來收集微服務中的所有跟蹤資訊，同時保持基礎設施運作的低操作複雜性。
大多數分布式跟蹤系統在微服務調用圖的請求攝取點強制執行采樣政策。我們采取了一種基于頭部的混合采樣方法 (1)，允許為特定的、可配置的請求集記錄 100% 的跟蹤，同時繼續根據攝取點的政策集随機采樣流量。
這種靈活性使得 tracer 庫能夠在關鍵任務流微服務中記錄 100% 的 trace 資訊，同時在離線批處理資料等輔助系統中 盡可能少的收集資訊。我們的工程團隊在考慮到由于跟蹤而增加的資源使用率後，對其服務進行了性能調優。
(1) https://github.com/openzipkin-contrib/zipkin-secondary-sampling/blob/master/docs/design.md
下一個挑戰是通過一個可擴充的資料處理平台來流式處理大量的跟蹤資料。
Mantis 是我們處理 Netflix 營運資料的首選平台。我們選擇 Mantis 作為傳輸和處理大量 trace 資料的主幹，因為我們需要一個背壓感覺、可擴充的流處理系統。跟蹤資料收集代理通過 Mantis Publish 庫 (1) 将跟蹤資料傳輸到 Mantis 作業叢集。
(1) https://netflix.github.io/mantis/internals/mantis-publish/
我們對一個時間段的跨度進行緩沖，以便在第一個作業中收集一個跟蹤的所有跨度。第二個作業從第一個作業中擷取資料源，對資料進行尾部采樣，并将 trace 寫入存儲系統。這種鍊式 Mantis 作業 (1) 的設定，使我們能夠獨立地擴充每個資料處理元件。
使用 Mantis 的另一個優勢是能夠使用 Mantis 查詢語言 (MQL) (2) 在 Raven 中執行實時的臨時資料探索。
(1) https://netflix.github.io/mantis/getting-started/concepts/#job-chaining
(2) https://netflix.github.io/mantis/reference/mql/
然而，如果你沒有低成本的資料存儲手段，擁有一個可擴充的流處理平台并沒有什麼幫助。
存儲：盡量節約
由于 Elasticsearch 具備靈活的資料模型和查詢能力，我們一開始就使用 Elasticsearch 作為資料存儲。随着入駐更多的流媒體服務，trace 資料量開始成倍增長。由于高資料寫入率導緻 ElasticSearch 叢集擴充的操作負擔增加，這讓我們感到很痛苦。資料讀取查詢需要越來越長的時間來完成，因為 ElasticSearch 叢集使用了大量的計算資源來為新增的 trace 建立索引。
高資料攝取率最終降低了讀寫操作。我們通過遷移到 Cassandra 作為資料存儲來解決這個問題，以處理高資料寫入量。在 Cassandra 中使用簡單的查找索引，使我們有能力在進行大量寫入時保持可接受的讀取延遲。
理論上，橫向擴充可以讓我們處理更高的寫入率，并在 Cassandra 叢集中保留更大量的資料。這意味着存儲 trace 的成本與存儲的資料量呈線性增長。我們需要确儲存儲成本的增長與存儲的資料量呈亞線性關系。為了追求這個目标，我們概述了以下存儲優化政策。
在 EC2 中使用更便宜的 Elastic Block Store(EBS) 卷而不是 SSD 執行個體存儲。
采用更好的壓縮技術來減少 trace 資料大小。
通過使用一些簡單的基于規則的過濾器，隻存儲相關和有用的 trace 資料。
每當現有節點的 EC2 SSD 執行個體存儲達到最大存儲容量時，我們就會增加新的 Cassandra 節點。使用更便宜的 EBS 彈性卷，而不是 SSD 執行個體存儲，是一個更合适的選擇，因為 AWS 允許動态增加 EBS 卷的大小，而無需重新建立 EC2 節點。這使我們能夠在不向現有叢集添加新的 Cassandra 節點的情況下增加總存儲容量。
2019 年，我們雲資料庫工程（CDE）團隊的厲害的同僚為我們的用例進行了 EBS 性能基準測試，并将現有叢集遷移到使用 EBS 彈性卷。通過優化時間視窗壓縮政策（TWCS）參數，他們減少了 Cassandra SSTable 檔案的磁盤寫入和合并操作，進而降低了 EBS 的 I/O 速率。
這種優化幫助我們減少了叢集節點之間的資料複制網絡流量，因為 SSTable 檔案的建立頻率低于之前的配置。此外，通過在 Cassandra 資料檔案上啟用 Zstd 塊壓縮，跟蹤資料檔案的大小減少了一半。有了這些優化後的 Cassandra 叢集，現在營運叢集的成本降低了 71%，而且可以比之前的配置多存儲 35 倍的資料。
我們觀察到，Edgar 使用者使用了不到 1% 的收集跟蹤資料。這讓我們相信，如果放棄那些使用者不會關心的跟蹤資料，可以減少寫入壓力，并在存儲系統中儲存更多的資料。
目前，我們在 Storage Mantis 工作中使用了一個簡單的基于規則的過濾器，它可以保留 Edgar 中很少被檢視的服務調用路徑的有趣跟蹤資訊。該過濾器通過檢查一個跟蹤的所有緩沖跨度的警告、錯誤和重試标簽，将一個跟蹤限定為一個有趣的資料點。這種基于尾巴的采樣方法在不影響使用者體驗的情況下，将跟蹤資料量減少了 20%。
我們有機會使用基于機器學習的分類技術，來進一步減少跟蹤資料量。
雖然已經取得了實質性的進展，但最近面臨建構跟蹤資料存儲系統的另一個拐點。在 Edgar 上增加一些新的功能可能需要我們存儲 10 倍于目前資料量的資料。
是以，目前正在試驗一種新的資料網關的分層存儲方式。這個資料網關提供了一個查詢接口，抽象了從分層資料存儲中讀取和寫入資料的複雜性。此外，資料網關将攝入的資料路由到 Cassandra 叢集，并将壓縮後的資料檔案從 Cassandra 叢集傳輸到 S3。我們計劃将最近幾個小時的資料保留在 Cassandra 叢集中，其餘資料保留在 S3 桶中，以便長期保留跟蹤資訊。
表格1：存儲優化的時間表
其他收益
除了支援 Edgar 外，跟蹤資料還用于以下使用場景。
應用程式健康監測
Trace 資料是 Telltale 用于監控 Netflix 宏觀層面應用健康狀況的關鍵信号。Telltale 使用 trace 中的關聯資訊來推斷微服務拓撲，并将 trace 與 Atlas 的時間序列資料相關聯。這種方法可以描繪出更豐富的應用健康狀況的可觀察性畫像。
容錯工程
我們的混沌工程團隊使用 trace 來驗證故障是否被正确注入，同時工程師通過故障注入測試（FIT）平台對其微服務進行壓力測試。
地域容災
需求工程團隊利用跟蹤資料來提高地域遷移期間伸縮的正确性。追蹤提供了與微服務互動的裝置類型的可見性，這樣，當 AWS 區域遷移時，可以更好地解釋這些服務需求的變化。
評估運作 A/B 測試的基礎設施成本
資料科學和産品團隊通過分析相關 A/B 測試名稱的 trace 資訊，評估微服務上運作 A/B 測試的效果。
下一步是什麼？
随着 Netflix 的發展，系統的範圍和複雜性不斷增加。我們将專注于以下幾個方面來擴充 Edgar。
- 為收集所有運作時環境的 trace 提供良好的開發者體驗。如果有簡單的方法來嘗試分布式跟蹤，将吸引更多工程師用跟蹤系統來檢測他們的服務，并通過标記相關的中繼資料為每個請求提供額外的上下文。
- 增強查詢跟蹤資料的分析能力，使公司的一些高階使用者能夠針對特定的用例建構自己的儀表盤和系統。
- 建構通用的能力，将來自名額、日志和跟蹤系統的資料關聯起來，為故障排除提供額外的上下文資訊。
随着我們在建構分布式跟蹤基礎設施方面的進展，工程師繼續依靠 Edgar 來解決諸如“為什麼 Tiger King 在我的手機上不能播放”之類問題，我們的分布式追蹤基礎設施有助于確定 Netflix 使用者繼續享受像 Tiger King 這樣的必看劇目！
英文原文：
https://netflixtechblog.com/building-netflixs-distributed-tracing-infrastructure-bb856c319304
參考閱讀：
- AIOps在美團的探索與實踐——故障發現篇
- 一個加班多新人多團隊，我們的代碼問題與重構
- 6種常用的架構設計模式（上）
- 專家說别用 if-else 編碼方式，那代碼怎麼寫
- Netflix雲原生微服務設計分析