背景

隨著字節(jié)跳動業(yè)務規(guī)模不斷擴大，對存量和新增業(yè)務的服務質量承諾變得越發(fā)關鍵。穩(wěn)定性治理方面：怎樣支持保障服務線上的高可用性，或者在出現(xiàn)故障/事故時，如何高效且迅速地止損、定位分析影響面已成為一個重要議題。

穩(wěn)定性建設所涉及的話題十分廣泛，涵蓋流程梳理與標準化、數(shù)據(jù)標準化、SLO 定義、故障自愈、事故復盤和演練等方面，字節(jié)跳動基礎架構可觀測團隊提供的穩(wěn)定性平臺建設思路是“事前預防、事中處理、事后復盤、事后補救/反哺事前”這四個階段。

其中， 觀測數(shù)據(jù)標準化以及一系列配套的數(shù)據(jù)鏈路，如：數(shù)據(jù)埋點、數(shù)據(jù)消費、數(shù)據(jù)存儲、數(shù)據(jù)查詢、離線數(shù)倉等，都是后續(xù)穩(wěn)定性建設的重要數(shù)據(jù)基石。

并且，由此引申出排障/止損效率的問題，由于字節(jié)的服務/基礎設施是分層建設的，包括端側客戶體驗層、網(wǎng)絡接入層、應用服務層、基礎設施層、IDC\資源層等，不同層面的統(tǒng)計/描述口徑是否一致、能否對應，以達到在跨層間能上卷下鉆和平層內(nèi)過濾聚合的“車同軌書同文”效果，這對于大幅提升整體排查效率， 讓 SRE/GOC 同學能夠自助完成端到端的問題排查就顯得尤為重要。

擁有統(tǒng)一的觀測數(shù)據(jù)標準， 能夠在很大程度上提升團隊間的排障效率，從人工分析的方式提升至更大程度的自助/自動化排障的階段。

埋點標準化的重要性

提高研發(fā)效率 & 降低研發(fā)協(xié)同成本

• 面向排障方面：跨層間的上下文過濾便捷，術語統(tǒng)一。
• 進行歷史數(shù)倉分析（容量優(yōu)化）時，整體數(shù)據(jù)處理邏輯的適配成本會大幅降低。
• 用戶的學習曲線陡峭，理解心智負擔沉重。

為 AIOps 提供強有力的數(shù)據(jù)支撐

觀測數(shù)據(jù)屬于 AIOps 的五大基石（數(shù)據(jù)、知識、算法、代碼聯(lián)動、人機協(xié)同）之一。在清華裴丹老師的《AIOps 落地的 15 條原則》里，也都提及了數(shù)據(jù)的重要性。

擁有數(shù)據(jù)標準化和統(tǒng)一的訪問體驗，為后續(xù)穩(wěn)定性的終極目標 MTTR 1-5-10（1 分鐘發(fā)現(xiàn)，5 分鐘響應以及 10 分鐘快恢復）提供了數(shù)據(jù)層面的保障。包括同層數(shù)據(jù)的聚合 / 過濾，以及跨層數(shù)據(jù)的下鉆和上卷，都會有統(tǒng)一的使用方式。

名詞解釋

字節(jié)埋點標準化挑戰(zhàn)與拆解思路

挑戰(zhàn)：歷史上可觀測性埋點質量偏低

首先，我們對埋點標準化進行定義，包括但不僅限于如下的標準定義，包括覆蓋完整、定義統(tǒng)一、計量準確、面向引擎友好等四大方面。

簡而言之，在 2020 年以前，從覆蓋完整、定義統(tǒng)一、計量準確、面向引擎友好等維度來看，字節(jié)整體的觀測數(shù)據(jù)埋點存在一定的差距。

具體如下：

負載均衡 埋點

• 計量準確：中等水平

     a.存在較嚴重的打點丟失問題

• 面向引擎友好：較低水平

     a.指標打點對于配置預計算不友好

     b.指標名膨脹也比較嚴重

微服務 埋點

• 覆蓋完整：中等水平

     a.20 年前 Tracing 方案還在 V1 版本

• 計量準確：中等水平

     a.遇到高基數(shù)的指標會被封禁

• 面向引擎友好：較低水平

     a.指標打點對于配置預計算不友好

     b.指標名膨脹也比較嚴重

     c.加權計算也不好實現(xiàn)

語言運行時 埋點

• 定義統(tǒng)一：較低水平

     a.Golang & C++ 框架 不同的版本定義的指標格式都不太一樣

• 面向引擎友好：較低水平

     a.指標打點對于配置預計算不友好

容器指標 埋點

• 覆蓋完整：較低水平
• 沒有日志采集覆蓋
• 計量準確：中等水平
• 遇到高基數(shù)的指標會被封禁
• 面向引擎友好：較低水平
• 指標打點對于配置預計算不友好

基礎架構存儲 & 數(shù)據(jù)庫 埋點

• 覆蓋完整：較低水平
• 存儲、數(shù)據(jù)庫、MQ 客戶端沒有黃金指標打點
• 沒有日志采集覆蓋
• 計量準確：較低水平
• 不同存儲、數(shù)據(jù)庫、MQ 產(chǎn)品打點格式 都不一
• 面向引擎友好：較低水平

     a.指標打點對于配置預計算不友好

思路：分層&向后兼容推進埋點標準化

總結來說，之前的字節(jié)服務端觀測數(shù)據(jù)質量大致存在三類問題。

• 同層數(shù)據(jù)/跨層數(shù)據(jù)不一致。
• 觀測的多模態(tài)數(shù)據(jù)類型（指標、日志、鏈路）的數(shù)據(jù)定義不統(tǒng)一。
• 觀測數(shù)據(jù)格式對引擎不夠友好，例如所有數(shù)據(jù)都在 default 租戶的一個大倉里，再比如很多觀測指標的定義對于預計算不友好。

針對上述問題，我們采取了如下的多個思路逐一進行解決。

實施思路

一方面，在埋點側就盡可能統(tǒng)一埋點 TagKV 定義，而且平臺級 TagKV 都通過環(huán)境變量或者請求上下文自動注入對應的 Tag Value， 以防止由業(yè)務手工注入帶來的人工錯誤。

另一方面，對于指標、鏈路和日志侵入式 SDK，我們通過字節(jié)內(nèi)部的遠程過程調(diào)用框架以及存儲、數(shù)據(jù)庫、消息中間件的客戶端 SDK 搭載嵌入中間件，對于業(yè)務來說，能相對透明地升級到最新特性的版本。另外， 對于遠遠低于 SDK 基線版本的服務， 我們也通過字節(jié)軟件供應鏈安全治理平臺通過編譯卡點的不同程度[warning 提示/發(fā)布卡點]推動業(yè)務升級。

在 負載均衡、應用、中間件、存儲計算組件等各個縱向方面， 我們也主動與對應的平臺對接，推動指標、日志、鏈路的埋點注入。

最后，在指標埋點上也額外關注對于多租戶的聲明，以達到一定的分庫分表功能，以及多值聲明，以最大程度減少數(shù)據(jù)消費和存儲成本。如下所示， 就是團隊在各個不同觀測對象的埋點方面所做的業(yè)務推進情況。

難點：識別和解決

類似觀測數(shù)據(jù)標準化的工作歷經(jīng)多年，牽涉的團隊眾多，整個過程并非毫無波折。遇到問題時要解決問題并思考能否將其標準化或者平臺化，同時也要考慮能否盡可能地復用其他團隊的能力和工具來助力我們進一步推廣。當時如何高效地推動業(yè)務升級是我們的主要目標。

[業(yè)務推進] 高效推動業(yè)務升級觀測SDK

在 Metrics SDK 需要升級到基線版本的情況下，以前的做法是在字節(jié)軟件供應鏈安全治理平臺上配置版本攔截，提醒用戶升級，但是整體升級效率比較低，我們也無法跟蹤用戶的升級進展。因此我們聯(lián)合字節(jié)軟件供應鏈安全治理平臺團隊實現(xiàn) SDK 自動升級功能。

Metrics SDK 自動升級

Metrics SDK 自動升級功能可以自動實現(xiàn)在當前業(yè)務代碼庫的代碼提交期間，如果檢測到對應集成的metrics SDK 低于基線版本，則會向用戶推送代碼提交失敗的通知，提醒用戶需要主動升級到metrics SDK基線版本或以上的操作。

遠程過程調(diào)用 框架 & 基礎組件客戶端 集成 BytedTrace SDK 集成

觀測團隊多年來持續(xù)推動公司的遠程過程調(diào)用 框架以及基礎組件客戶端 集成 BytedTrace SDK 。借助字節(jié)軟件供應鏈安全治理平臺進行遞進式卡點推廣，依靠代碼血緣平臺來推動框架、組件的基礎庫版本實現(xiàn)升級。在存有流量的微服務上，BytedTrace SDK的覆蓋比例按照 TCE pod 接入情況來計算，當前已達到 95%。

從服務的優(yōu)先級角度而言，公司當前96% 的 P0 服務中已接入 Bytedtrace SDK 。

[業(yè)務推進] 提升基礎組件觀測埋點質量

TCE 調(diào)度 / 運行時 打點格式設計思路

前文提到，提升業(yè)務層、應用層、容器層等多層間指標的跨層關聯(lián)和下鉆能力是指標標準化的一個重要目標，而實現(xiàn)跨層關聯(lián)的關鍵動作在于保證同一含義的指標 TagKV 在各層上的定義保持統(tǒng)一，為實現(xiàn)這一點，我們對各個層次上的核心組件進行了統(tǒng)一的設計，具體如下：

• 縱向上，對齊Metrics 2.0 SDK 平臺級TagKV規(guī)范 | | 容器層 | 與調(diào)度合作，對容器指標采集agent(TCE調(diào)度)進行標準化改造 | -   對齊Metrics 2.0 SDK 平臺級TagKV規(guī)范                             |

1. 首先，我們在 Metrics 2.0 SDK 內(nèi)置定義了一套平臺級 TagKV，這樣所有使用 Metrics 2.0 SDK 的業(yè)務打點都會攜帶標準的預定義的 TagKV。這些共同TagKV包括：_cluster、_psm、_pod_name、_ipv4 等。
2. 在應用層，挑選了對業(yè)務排障、應用觀測常用且通用的兩類指標（運行時、遠程過程調(diào)用）進行標準化，目標是在橫向上，提供跨語言、統(tǒng)一的指標名、TagKV語義定義等；在縱向上，對齊 Metrics 2.0 SDK 平臺級 TagKV 規(guī)范，以便于跨層關聯(lián)。以 運行時 指標為例，其定義規(guī)范如下：

     a.不同語言的指標采用統(tǒng)一命名約定：runtime. {runtime} . {metric}[ . {field}]

     b.不同語言類似含義指標采用統(tǒng)一命名風格：如 go、java 中統(tǒng)計堆對象申請量的指標都命名為memory.allocated_bytes

     c.必須包含 Metrics 2.0 SDK TagKV 規(guī)范的平臺級 TagKV，如 _psm、_pod_name 等

3. 在容器層，與調(diào)度團隊共同推動其 TCE 容器指標采集 agent(TCE調(diào)度) 的指標標準化改造，指標 TagKV 對齊Metrics 2.0 SDK TagKV 規(guī)范。

通過將這些核心組件進行標準化改造，為跨層的指標關聯(lián)和下鉆提供了能力基礎。同時，在每個核心組件的指標定義上，我們還通過以下兩個方式進一步提升埋點的性能和成本收益，第一點是對各個組件使用獨立租戶，實現(xiàn)資源的隔離，保障寫入穩(wěn)定性和查詢性能；

第二點是在語義明確的前提下，盡量使用多值格式定義指標，降低存儲成本。以 TCE調(diào)度 指標為例，將原來 mem 相關的四個指標合并為一個多值指標的四個字段，存儲成本大致可以被認為降低至四分之一。

[配套工具] 幫助平滑遷移觀測數(shù)據(jù)

[工具1] 語義化指標替換

我們提供語義化指標替換，稱為Measurement，其能力就是對原始 Metrics 打點的語義化封裝；同時能識別在不同條件下應該使用哪個版本的指標以及對應的 TagKV。這兩個關鍵能力能夠促使在做數(shù)據(jù)遷移時，觀測大盤和報警基本達到比較平滑的狀態(tài)。

原始 Metrics 打點：直接寫入時序數(shù)據(jù)庫（可以是 metrics \ influxdb \ prometheus）的數(shù)據(jù)。

語義化封裝：用標準的語義化來包裝原始的 metrics 打點數(shù)據(jù)。比如 go 服務的 gc 數(shù)量的 metrics 打點是 go.{{.psm}}.numGcs，其中{{.psm}}為具體的 psm， 我們會定制一個語義化指標名叫 "runtime.go.gc_num"來表達 go 服務的 gc 數(shù)量，包括用統(tǒng)一的 TagKV 來封裝對應的原始 TagKV。不管是 open api 還是前端調(diào)用， 都用指標 "runtime.go.gc_num" 對measurement 服務進行調(diào)用。

不同條件下的查詢路由：需要這個能力是因為在字節(jié)內(nèi)部原始 Metrics 的打點會不斷的升級， 比如 golang 運行時 歷史上會有 v1 、v2 、v3 多個版本，我們需要能夠在給定的輸入信息條件下去查詢到對應的指標版本。這個判斷條件實現(xiàn)的邏輯一般為可用輸入的 psm 名字構成 Metrics go v1 的指標名，再根據(jù)指標名的數(shù)據(jù)是否存在來判斷是 runtime v1、runtime v2 或者 runtime v3 的版本，指標判斷也以此類推。或者可以通過 psm 的 scm 編譯信息確定該 psm 編譯的 golang 運行時 版本是 v1、v2 或者 v3。通過對應條件的判斷來做到對應數(shù)據(jù)的查詢路由。

在有了 Measurement 能力后，我們抽象出了 Measurement 服務，該服務作為觀測大盤和報警的一個數(shù)據(jù)源。在盡量不需要用戶介入的情況下完成數(shù)據(jù)打點的遷移和替換。

當前借助 Measurement 能力，針對公司的 遠程過程調(diào)用、HTTP 等框架，容器引擎、FaaS、機器學習推理等平臺，還有負載均衡、緩存、數(shù)據(jù)庫、消息隊列等基礎組件，以及golang 運行時 等，均進行了統(tǒng)一的標準化語義封裝，這些語義化封裝在觀測平臺上均有所展現(xiàn)。

[工具2] Metrics 前綴分流

怎樣幫助業(yè)務順利地遷移到新租戶，同時確保新老指標的查詢方式均可使用，是我們在推動業(yè)務租戶遷移時所面臨的較大挑戰(zhàn)。

針對上述問題，觀測團隊起初推進引導用戶主動遷移至新租戶，旨在實現(xiàn)租戶隔離，提供更優(yōu)的穩(wěn)定性保障，進行精細化容量治理以降低成本。然而，后來發(fā)現(xiàn)主動遷移的速度太慢，趕不上打點量的自然增長。于是，推出了讓用戶無感知的被動租戶遷移方案。大致思路是依據(jù)某些特定的指標前綴，主要涵蓋一級 / 二級前綴，通過特定配置把這些指標分別路由到不同的新租戶，并且在新租戶上支持查詢翻譯，即便用戶不修改查詢租戶，繼續(xù)用 Default 租戶查詢?nèi)阅苷＋@取數(shù)據(jù)。該方案具有以下優(yōu)勢：

1. 業(yè)務在讀寫兩側無需進行代碼變更，就能將流量遷移到新租戶集群。
2. 最大程度減少不同租戶間因集群變更和讀寫流量變化對線上穩(wěn)定性產(chǎn)生的相互影響，提供更出色的穩(wěn)定性保障。
3. 精準對接業(yè)務線租戶，便于后續(xù)進行打點流量治理、容量規(guī)劃以及資源充值等操作。

具體的實現(xiàn)由 Metrics 組件中各模塊的相互配合完成，包括寫入、控制面、查詢、數(shù)倉等方面，大致的實現(xiàn)流程如下：

前綴分流租戶的整個過程存在眾多細節(jié)，為減少過程中的過多人為操作，防止出現(xiàn)某些環(huán)節(jié)被遺忘的情況，觀測團隊設計了分流流程工單以及白屏化運維平臺，盡可能讓整個操作流程實現(xiàn)自動化，提高分流租戶的效率。此外，前綴分流遷移新租戶的整個過程對于業(yè)務來說成本為零，同時對于 觀測團隊而言不像依賴業(yè)務方主動遷移那樣周期漫長，其周期短、生效時間快，能夠收斂團隊人力的持續(xù)投入。

總的來說，觀測團隊提供了一種讓用戶無感知、實現(xiàn)無縫遷移新租戶的方案，用戶的核心觀測大盤和報警也無需修改，最大程度降低了埋點標準化對用戶的打擾。

埋點標準化字節(jié)的實踐與效果

觀測數(shù)據(jù)質量前后對比

經(jīng)過 2020-2022 年推進 BytedTrace SDK 覆蓋率、2023 年推動云基礎組件和應用層指標租戶遷移之后， 從埋點標準化的 4 個維度看，都有不同程度的質量提升。

負載均衡

-計量準確：較高水平 [2020年為中等水平]

• 通過 2.0 SDK 三個特性， 基本消除丟點的問題：

     a.打點本地聚合

     b.面向字節(jié)流的 codec 編碼

     c.Agentless 投遞

-面向引擎友好：較高水平 [2020年為較低水平]

• 實現(xiàn)面向預計算友好的效果

-成本收益：

• Metrics 2. 0 打點商品成本相對 1.0 下降 94%
• Metrics 2. 0 很好地解決了打點封禁問題，特別是在一些配置量巨大的核心集群，解決了其超過 90%打點無法查詢的情況
• Metrics2. 0 TLB 機器成本初步統(tǒng)計主容器和 adaptor 打平，同時相對 1.0 節(jié)約了 ms2 的 15000 核資源

微服務

-覆蓋完整：較高水平 [2020年為中等水平]

• 80%以上 PSM 覆蓋到 BytedTrace SDK 集成

-計量準確：中等偏上水平 [2020年為中等水平]

• 高基數(shù)的指標封禁問題 由于遷移到了新租戶 可以做封禁閾值定制化

• [計劃中] 升級 bytedTrace 內(nèi)的 metrics 2.0 SDK 降低丟點的風險

-面向引擎友好：較高水平 [2020年為較低水平]

• 實現(xiàn)面向預計算友好的效果

-成本收益：

• 以計算關鍵組件 Consumer 為例，新租戶只需要老租戶 20%的資源，就可以完成相同數(shù)據(jù)的寫入計算；其他寫入計算類組件也類似
• 以存儲關鍵組件 tsdc 為例，新租戶只需要老租戶 55%的資源，就可以完成數(shù)據(jù)的寫入、存儲

語言 運行時

• 定義統(tǒng)一：較高水平 [2020年為較低水平]
• 統(tǒng)一了不同語言和框架的 運行時 打點格式

容器指標

-覆蓋完整：中等水平 [2020年為較低水平]

• TCE調(diào)度 接入日志租戶

-計量準確：較高水平 [2020年為中等水平]

• 引入多值 降低指標名數(shù)量
• 高基數(shù)的指標封禁問題 由于遷移到了新租戶 可以做封禁閾值定制化
• 通過 2.0 SDK 三個特性， 基本消除丟點的問題

    a.打點本地聚合

    b.面向字節(jié)流的 codec 編碼

    c.Agentless 投遞

-面向引擎友好：較高水平 [2020年為較低水平]

• 實現(xiàn)面向預計算友好的效果

基礎架構 存儲 & 數(shù)據(jù)庫

-計量準確：較高水平 [2020年為中等水平]

• 引入多值 降低指標名數(shù)量
• 高基數(shù)的指標封禁問題 由于遷移到了新租戶 可以做封禁閾值定制化
• 通過 2.0 SDK 三個特性， 基本消除丟點的問題
• 打點本地聚合
• 面向字節(jié)流的 codec 編碼

-面向引擎友好：中等水平 [2020年為較低水平]

• 打點格式調(diào)整的 支持預計算配置

-成本收益：

• 以 mysql 遷移為例

     a.Mysql 租戶 成本節(jié)省 45.7%

     b.Mysql 租戶 帶寬節(jié)省了 80%

截止到今年年初， Metrics 在中國國內(nèi)區(qū)域已經(jīng)接入 60+ 租戶，占總流量的 70% 左右。

賦能效果總結

加速微服務端到端根因定位

通過指標標準化 & 多模觀測數(shù)據(jù) [指標， 日志，鏈路]標簽術語的標準化， 我們實現(xiàn)面向微服務的上卷 & 下鉆關聯(lián)分析。

也使得使得跨層問題根因分析有了可能性：

目前端到端根因定位覆蓋了60%以上的報警場景，日均觸發(fā)根因定位 50余萬 次，用戶對定位結果的正反饋率超過80%。

簡化服務性能離線數(shù)倉構建

在實現(xiàn)了在線觀測數(shù)據(jù)的標準化，并將其導入統(tǒng)一的存儲介質之后，構建字節(jié)整體關于服務性能、容量、吞吐量的數(shù)倉大盤就更加便捷。比如 展現(xiàn)某服務的單核 QPS 分時熱力圖 如下:

目前基于微服務應用性能數(shù)倉已覆蓋公司超97%的微服務量化，有效支持字節(jié)跳動各業(yè)務線服務性能、服務應用健康度度量，由此帶動一系列精準的成本優(yōu)化。

觀測底座自身收益

• 從穩(wěn)定性角度看，由于引入metrics多租戶概念，所以我們能夠通過邏輯租戶映射到物理資源，從而降低故障半徑，減少不同租戶間流量的相互干擾。
• 從成本角度看，我們能夠依據(jù)每個租戶的副本數(shù)、存儲時長 TTL、打點的最小精度以及多值定義，最大程度地降低寫入流量和存儲容量的成本。metrics 多租戶遷移前后對比，成本節(jié)省幅度在 20% ~ 80% 不等。

總結

歷經(jīng)上述觀測埋點套件 BytedTrace SDK推廣、Metrics 指標標準化遷移和推廣、部分業(yè)務接入日志多租戶，字節(jié)后端觀測數(shù)據(jù)的質量在覆蓋完整度、定義統(tǒng)一、計量準確、面向引擎友好四個方面上取得了顯著的質量提升。這也為后續(xù)的全景全棧高效排障奠定了堅實的基礎，幫助更多業(yè)務團隊在業(yè)務穩(wěn)定性方向持續(xù)建設。

依托字節(jié)跳動內(nèi)部可觀測團隊大規(guī)模技術實踐，通過內(nèi)外合力，在火山引擎上推出了應用性能監(jiān)控全鏈路版（APMPlus）、托管 Prometheus（VMP）、云監(jiān)控等可觀測產(chǎn)品，致力于為用戶提供全面、智能、高效、易用且安全的全棧可觀測解決方案。

目前 APMPlus Server 端監(jiān)控已正式 GA 并支持最新的大模型鏈路追蹤相關能力，歡迎咨詢了解。

?? 相關鏈接

APMPlus ： www.volcengine.com/product/apmplus

VMP ： www.volcengine.com/product/prometheus

云監(jiān)控 ： www.volcengine.com/product/cloudmonitor